Just discovered:
Seems Haiku using compromised version (5.6.1) of the library:
It needs to be removed and investigated. Although the Haiku version probably doesn’t have compromising binary blob.
1 Like
HaikuPorts has already been updated to use a safe source:
Based on mailing list discussions, the next courses of action are to wait for official fixes from xz then do a mass rebuild of packages that depend on it.
@kallisti5 and @jmairboeck could prolly talk more about this if necessary.
I terribly hate those yt videomakers, who uses this kind of thumbnails with the over-dimensioned feelings on their faces, be either disgust or amazement or something else. Long story short, i think those videomakers are simply profiting on utter ignorance and their talk is scripted by llm, which lets them talk much but say nothing.
Thanks for advertising those videomakers.
7 Likes
This has already been announced by kallisti5 and „fixed“ in haikuports.
Haiku likely was not targetable by this specific exploit in the first place, however the malicious contributor has added more code too.
So we will have to see how upstream resolves this.
2 Likes
This backdoor requires sshd in /usr/sbin/sshd to work. So it’s not gonna work on Haiku, unless you patch it to provide some Haiku support.
Malware is software, so you get your usual software problems like poor performance (which helped to discover the xz backdoor in the first place) or not working on non-standard platforms.
1 Like
Why is a compression utility doing so many different things ?? I would think that is the core issue. It should only be a algorithm.
haiku-security Mailing List Archive 
I also tossed together security: Improve our posture to announce critical CVEs by kallisti5 · Pull Request #672 · haiku/website · GitHub to document “critical CVE’s” impacting Haiku. Trying to decide if it’s worth taking on one more thing to maintain with such a small team of developers.
4 Likes
We can switch to another software equivalent to xz: GitHub - vasi/pixz: Parallel, indexed xz compressor
2 Likes
I‘ve read this one recently too, it makes me think we shouldn’t support xz in any way other than ro/extracting „best effort“
This attack in general raises another question though, assuming anyone wants to attack Haiku, what is preventing them from using prebuilt binaries in haikuports, or replicants?
Since replicants work by loading another progranm into it‘s own adresss space such attacks would lilely be much easier on Haiku, if you can trick the programm to load you. Is there a deffence against this?
A ‘better’ implementation of an LZMA compressor is Lzip: https://depot.haiku-os.org/#!/pkg/lzip/haikuports/haikuports_x86_64/1/23/-/-/1/x86_64
This was very targeted to Linux, I would not overreact to how this affects Haiku.
The binary blob hidden in the test files is Linux x64 binary and the code which adds it even checks for the target being Linux. Only systemd is stupid enough to link in the xz library in a privileged memory location which allows the hacked functions to be replaced in sshd. Plus it likely requires Linux-specific runtime loader behavior. It really does require a lot of things to be exactly right in order to work.
It was definitely scary for Linux and somewhat for open source in general, showing the issue with depending on lone, unpaid developers. In that sense Haiku is in slightly better shape since we have somewhat of a team, even if it is small.
I feel bad for the guy who originally made the xz library, who is maybe the biggest victim here.
10 Likes
Too much fuss, if you ask me. Even in GNU/Linux, this was an incident only affecting specific distributions in their cutting edge rolling version (which I’ll never use anyway). And even then, it took years for the backdoor creator to gain trust so that his code was included. And of course, with the code being free and open source, it didn’t take long to discover the problem.
We were lucky this time. The code had some performance impacts, that someone noticed while running some completely unrelated benchmarks on postgresql. That person could very well have decided “weird, it’s openssl taking half a second longer than it used to when connecting to a server where it’t not allowed to connect” and moven on with whatever they were really benchmarking. They decided to dig deeper and found the problem.
The plan for the attacker almost worked. And if it had, it would have been worth the years of work, as it would allow to connect to pretty much any machine. We don’t know who they were targetting, maybe they already succeeded in infiltrating the machine they wanted to. Probably this was not a single isolated case and they tried this on multiple projects at the same time. Maybe some of these attempts failed at earlier steps. Maybe some succeeded and we’ll never know.
It shows that the ecosystem is not really ready to handle this type of attack, when the attacker manages to get control of a project with the collaboration of the existing developers. This also shows that the model of opensource where people just get things for free and don’t pay the developersfor their work makes the opensource developer an “attack surface”, which can be exploited by pressuring them to make more releases, or transferring ownership of their projects if they can’t. There are some things to think about here, otherwise this will happen again and again.
3 Likes
I don’t think the open source project alone is vulnerable to such criminal activities. The difference is that if this has happened in closed source projects, public haven’t found out. On the other hand, the company itself, using a closed code, can engage in criminal or shady activities without outside interference. And I don’t think anyone here would be surprised by that.
2 Likes