Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Excellent succinct breakdown of the xz mess, from an OpenBSD developer

marc.info

Post reply on HN
Print view View original

41–50 of 54 posts

Re: Excellent succinct breakdown of the xz mess, from an OpenBSD developer

#41

Post by cryptonector »

ryanjshaw wrote: post #34

> the build-to-host.m4 macro package that ships as part of GNU gettext was replaced by a modified version that was copied into the release tarball Am I correct in concluding that this backdoor might have been picked up sooner if the practice of shipping tarballs of source releases was dropped in favour of running builds straight off a repo tag? I've setup and worked with many build pipelines in the .NET world over ne…

> Am I correct in concluding that this backdoor might have been picked up sooner if the practice of shipping tarballs of source releases was dropped in favour of running builds straight off a repo tag?

I don't think so. The git repo did have everything needed. The release tarball thing was just an added benefit to the attackers, but not critical. IMO.

> I've setup and worked with many build pipelines in the .NET world over nearly 20 years and we manage fine without the concept of a source release tarball, but I realise C dev is more complex so I'm probably missing something?

.Net, but, portable .Net?

The issue isn't the language but what things you need to detect presence of in the target host when building, and if you're doing systems programming you're likely to need to detect many such things, and if you're doing more high level programming (e.g., an HTTP app that uses a DB) then you're not likely to need to detect many such things.

The real issue is the variance from standards (e.g., POSIX) and the fact that the standards (e.g., POSIX) are so far behind because they really just standardize the lowest common denominator.

Re: Excellent succinct breakdown of the xz mess, from an OpenBSD developer

#42

Post by rany_ »

NekkoDroid wrote: post #38
rany_ wrote: post #27

Earlier quoted context omitted.

We only know it's malicious in hindsight. If I was Lasse (original xz maintainer) I could have easily thought it was an innocent typo and that's the point. If it was more convoluted like zero-width Unicode character or misspelling of variable names, it'll be less plausible IMO.

The thing is, if anyone would have actually realized it (other than Jai) it would have been hopefully fixed. Like... no one would just see that and say "well, must have been a typo" and just leaves it.

You're missing the years of reputation Jia built so that he'd be given the benefit of the doubt. I don't think anyone would have been too suspicious.

Re: Excellent succinct breakdown of the xz mess, from an OpenBSD developer

#43

Post by ryanjshaw »

cryptonector wrote: post #41
ryanjshaw wrote: post #34

> the build-to-host.m4 macro package that ships as part of GNU gettext was replaced by a modified version that was copied into the release tarball Am I correct in concluding that this backdoor might have been picked up sooner if the practice of shipping tarballs of source releases was dropped in favour of running builds straight off a repo tag? I've setup and worked with many build pipelines in the .NET world over ne…

> Am I correct in concluding that this backdoor might have been picked up sooner if the practice of shipping tarballs of source releases was dropped in favour of running builds straight off a repo tag? I don't think so. The git repo did have everything needed. The release tarball thing was just an added benefit to the attackers, but not critical. IMO. > I've setup and worked with many build pipelines in the .NET worl…

> The release tarball thing was just an added benefit to the attackers, but not critical. IMO.

What I mean is that Debian and Fedora presumably download the tarball and build from there, rather than cloning a repo and building from the repo.

If they did the latter, it would have been much more difficult to manipulate the build process to inject the backdoor that lived inside the testcase binaries, because that change to the build scripts would be out in the open.

But I could be mistaken...

Re: Excellent succinct breakdown of the xz mess, from an OpenBSD developer

#44

Post by edflsafoiewq »

cryptonector wrote: post #41
ryanjshaw wrote: post #34

> the build-to-host.m4 macro package that ships as part of GNU gettext was replaced by a modified version that was copied into the release tarball Am I correct in concluding that this backdoor might have been picked up sooner if the practice of shipping tarballs of source releases was dropped in favour of running builds straight off a repo tag? I've setup and worked with many build pipelines in the .NET world over ne…

> Am I correct in concluding that this backdoor might have been picked up sooner if the practice of shipping tarballs of source releases was dropped in favour of running builds straight off a repo tag? I don't think so. The git repo did have everything needed. The release tarball thing was just an added benefit to the attackers, but not critical. IMO. > I've setup and worked with many build pipelines in the .NET worl…

> I don't think so. The git repo did have everything needed.

build-to-host.m4 is not checked into the repo. Without the modified build-to-host.m4, there is nothing to kick off the exploit.

Re: Excellent succinct breakdown of the xz mess, from an OpenBSD developer

#45

Post by neonsunset »

cryptonector wrote: post #41
ryanjshaw wrote: post #34

> the build-to-host.m4 macro package that ships as part of GNU gettext was replaced by a modified version that was copied into the release tarball Am I correct in concluding that this backdoor might have been picked up sooner if the practice of shipping tarballs of source releases was dropped in favour of running builds straight off a repo tag? I've setup and worked with many build pipelines in the .NET world over ne…

> Am I correct in concluding that this backdoor might have been picked up sooner if the practice of shipping tarballs of source releases was dropped in favour of running builds straight off a repo tag? I don't think so. The git repo did have everything needed. The release tarball thing was just an added benefit to the attackers, but not critical. IMO. > I've setup and worked with many build pipelines in the .NET worl…

In .NET specifically it's not an issue because taking on a dependency means you always get the source code in the form of IL assemblies with (usually) symbols (either way these trivially decompile back to readable-ish C#).

The actual final product you get is when publishing (building) the application itself, similar to Rust the way crates participate in the build process.

Nuget packages still can and do ship pre-compiled native dependencies but ideally you want to either provide your own (think sourcing libsodium separately and just getting the bindings from nuget) or instrument the corresponding .NET project to build a native dependency alongside it (very easy with properties in csproj).

Re: Excellent succinct breakdown of the xz mess, from an OpenBSD developer

#46

Post by logicprog »

zokier wrote: post #32
logicprog wrote: post #15

Earlier quoted context omitted.

> kinda wish this was unpacked a bit more, why exactly is a service executable dynamically linking to a library without using any of its symbols or functions, because of systemd. If I recall correctly based on what I've read about this — I believe from the original mailing list post that noticed the vulnerability — it's because under certain circumstances in order to enable certain functionality you might want sshd t…

> But obviously you need a library to implement actually speaking system's protocol That is overstatement. The docs have basic self-contained example how to implement the notification without libraries, its 50 lines, majority of which is just error handling: https://www.freedesktop.org/software/systemd/man/devel/sd_no...

Oh, cool! I was just trying to give the maximum benefit of the doubt, but this is good to know. The systemd hate never seems as justified as it'd like to be...

Re: Excellent succinct breakdown of the xz mess, from an OpenBSD developer

#47

Post by NekkoDroid »

rany_ wrote: post #42
NekkoDroid wrote: post #38

Earlier quoted context omitted.

The thing is, if anyone would have actually realized it (other than Jai) it would have been hopefully fixed. Like... no one would just see that and say "well, must have been a typo" and just leaves it.

You're missing the years of reputation Jia built so that he'd be given the benefit of the doubt. I don't think anyone would have been too suspicious.

I am not saying people would have said Jia is acting maliciously, just noone saw this to begin with else it would have been fixed in a separate patch (before the emergancy fix recently by Lasse)

Re: Excellent succinct breakdown of the xz mess, from an OpenBSD developer

#48

Post by rany_ »

NekkoDroid wrote: post #47
rany_ wrote: post #42

Earlier quoted context omitted.

You're missing the years of reputation Jia built so that he'd be given the benefit of the doubt. I don't think anyone would have been too suspicious.

I am not saying people would have said Jia is acting maliciously, just noone saw this to begin with else it would have been fixed in a separate patch (before the emergancy fix recently by Lasse)

XZ is just a really boring project. It seems complete for the most part, so I'm not surprised by the lack of scrutiny. It's one of these projects that I would just assume is well maintained.

Re: Excellent succinct breakdown of the xz mess, from an OpenBSD developer

#49

Post by fmajid »

waynesonfire wrote: post #5

> Liblzma ends up dynamically linked to sshd because of a systemd-related extension added by many Linux packagers that pulls in liblzma as an unrelated dependency kinda wish this was unpacked a bit more, why exactly is a service executable dynamically linking to a library without using any of its symbols or functions, because of systemd. and a follow up if some openbsd folks can comment. over the years i've read abou…

Systemd provides via libsystemd a call sd_notify() that tells systemd the daemon is not only started but ready to accept connections. libsystemd, being a kitchen-sink like everything else systemd, has a bunch of unrelated functionality including one that pulled liblzma as a dependency.

The backdoored liblzma relies on a misfeature of glibc called ifuncs, where a library can override a function by calling a special init function in the library. This is so for instance if you have a version of a function optimized for AVX512, one ofor AVX2 and one not optimized for those at all, the init function would check which features the CPU supports and picks the best one. Seemingly ifuncs doesn't check the function being overriden is in the same library, and it was replacing OpenSSH's RSA auth function.

OpenSSH added a clean-room libsystemd-free implementation of sd_notify() after this fiasco, in the hope Linux distros will stop linking against libsystemd, this will appear in OpenSSH 9.8:

https://bugzilla.mindrot.org/show_bug.cgi?id=2641

Re: Excellent succinct breakdown of the xz mess, from an OpenBSD developer

#50

Post by fmajid »

PreInternet01 wrote: post #2

> much of the emerging narrative about this backdoor that you can read all over the net is based on idle speculation ...which sums up the situation quite nicely. This was a pretty bad attack on a certain ecosystem. The ecosystem will recover, or not, regardless of your feelings. Unless you're in a position to truly make a difference, just sit back and enjoy the ride...

There is some protection to be had in using non-mainstream platforms (in my case, Alpine Linux, OpenBSD and Illumos, though I do have some Ubuntu or Pop-OS! laptops).
Post reply on HN