Live data from Hacker News

Story of XZ Backdoor [video]

youtube.com

21–30 of 55 posts

Re: Story of XZ Backdoor [video]

#21
post #19

Lovely video, going into almost everything... ...and yet, zero mention of systemd's recommendation for programs to link in the libsystemd kitchen sink just to call sd_notify() (which should really be its own library) ...and no mention of why systemd felt the need to preemptively load compression libraries, which it only needs to read/write compressed log files, even if you don't read/write log files at all? Again, it…

It did get mentioned - in the context of the upstream change to dynamically load those libraries being a threat to the hack's viability which may have caused "Jia Tan" to rush and accidentally make mistakes in the process.

They say "an open-source developer requests to remove the dependency that links xz to OpenSSH" while showing https://github.com/systemd/systemd/pull/31550 on screen, zoomed and focused so the word "systemd" does not appear.

They never once utter the word "systemd", anywhere in the script... isn't that strange for such a key dependency?

Re: Story of XZ Backdoor [video]

#22

Lovely video, going into almost everything... ...and yet, zero mention of systemd's recommendation for programs to link in the libsystemd kitchen sink just to call sd_notify() (which should really be its own library) ...and no mention of why systemd felt the need to preemptively load compression libraries, which it only needs to read/write compressed log files, even if you don't read/write log files at all? Again, it…

When I was being interviewed, we did talk about exactly this, including that libsystemd is a kitchen sink, and that eventually OpenSSH went with open-coding the equivalent to sd_notify instead of depending on libsystemd. (Also that ahem Red Hat added the dependency on libsystemd in a downstream patch oops).

However the editors (correctly IMHO) took the decision to simplify the whole story of dependencies. In an early draft they simplified it too much, sort of implying that sshd depended directly on liblzma, but they corrected that (adding the illustration of dependencies) after I pointed out it was inaccurate.

I agree with everything you say, but you have to pick your battles when explaining very complicated topics like shared libraries to a lay audience.

In general I was impressed by their careful fact checking and attention to detail.

Sadly they missed the misspelling (UNRESOVLED) even though I pointed it out last week :-( But that's literally the only thing they didn't fix after my feedback.

Re: Story of XZ Backdoor [video]

#23
post #12

https://boehs.org/node/everything-i-know-about-the-xz-backdo... This is the scariest part to me: > A pull request ( https://github.com/jamespfennell/xz/pull/2 ) to a go library by a 1Password employee is opened asking to upgrade the library to the vulnerable version

People are always trying to bump versions because it's (usually) an easy contribution.

Re: Story of XZ Backdoor [video]

#24
post #4

This is IMO one of the coolest tech stories to ever happen, seriously amazing spycraft & hacking skills, but I haven't been keeping up with new developments from this story since it broke. Last I heard, the best guess at what happened was some state-sponsored actor worked very hard to get this merged, and it was caught luckily at the last minute. But no one had any smoking gun as to who did it or why or who they were…

Stuxnet is also another mindblowing case. Wired write-up on it is a recommended reading: https://web.archive.org/web/20141028182107/http://www.wired....

Re: Story of XZ Backdoor [video]

#25
post #4

This is IMO one of the coolest tech stories to ever happen, seriously amazing spycraft & hacking skills, but I haven't been keeping up with new developments from this story since it broke. Last I heard, the best guess at what happened was some state-sponsored actor worked very hard to get this merged, and it was caught luckily at the last minute. But no one had any smoking gun as to who did it or why or who they were…

> and it was caught luckily at the last minute

This isn't correct at all. The changes were merged into xz and made it into testing branches of major Linux distros.

It was caught at T plus a few minutes only because a neurotic Microsoft employee performing debugging noticed an obscure performance issue.

You can literally say Microsoft saved Linux that day. Imagine thinking this 25 years ago.

It's the difference between something really bad which happened, and something really, really, really, really bad: a malicious actor having RCE credentials to every new Debian and Red Hat box on planet Earth.

Re: Story of XZ Backdoor [video]

#26
post #4

This is IMO one of the coolest tech stories to ever happen, seriously amazing spycraft & hacking skills, but I haven't been keeping up with new developments from this story since it broke. Last I heard, the best guess at what happened was some state-sponsored actor worked very hard to get this merged, and it was caught luckily at the last minute. But no one had any smoking gun as to who did it or why or who they were…

> and it was caught luckily at the last minute This isn't correct at all. The changes were merged into xz and made it into testing branches of major Linux distros. It was caught at T plus a few minutes only because a neurotic Microsoft employee performing debugging noticed an obscure performance issue. You can literally say Microsoft saved Linux that day. Imagine thinking this 25 years ago. It's the difference betwee…

Redhat actually stumbled on the bug separately with valgrind errors triggering, so it's days were likely numbered regardless. Probably saved them a lot of debugging but the writing was on the wall.

Re: Story of XZ Backdoor [video]

#27

Earlier quoted context omitted.

> and it was caught luckily at the last minute This isn't correct at all. The changes were merged into xz and made it into testing branches of major Linux distros. It was caught at T plus a few minutes only because a neurotic Microsoft employee performing debugging noticed an obscure performance issue. You can literally say Microsoft saved Linux that day. Imagine thinking this 25 years ago. It's the difference betwee…

Redhat actually stumbled on the bug separately with valgrind errors triggering, so it's days were likely numbered regardless. Probably saved them a lot of debugging but the writing was on the wall.

A lot of people fail to fully grasp how bad this could have been on the off chance the authors were slightly less sloppy.

Re: Story of XZ Backdoor [video]

#29

Lovely video, going into almost everything... ...and yet, zero mention of systemd's recommendation for programs to link in the libsystemd kitchen sink just to call sd_notify() (which should really be its own library) ...and no mention of why systemd felt the need to preemptively load compression libraries, which it only needs to read/write compressed log files, even if you don't read/write log files at all? Again, it…

From my vague memory of xz backdoor, I don't even recall systemd being involved. Now, I get what people are talking about when they said systemd is taking over everything and why there was so much pushback to systemd when it was being added to distros. For me as a end user/dev, it mattered little whether services were started by systemd, openrc etc.

Re: Story of XZ Backdoor [video]

#30
post #19

Earlier quoted context omitted.

It did get mentioned - in the context of the upstream change to dynamically load those libraries being a threat to the hack's viability which may have caused "Jia Tan" to rush and accidentally make mistakes in the process.

They say "an open-source developer requests to remove the dependency that links xz to OpenSSH" while showing https://github.com/systemd/systemd/pull/31550 on screen, zoomed and focused so the word "systemd" does not appear. They never once utter the word "systemd", anywhere in the script... isn't that strange for such a key dependency?

It probably is because of video length, mentioning systemd would mean explaining init system which could add another 5 min runtime. At least they showed it in diagram of dependencies.
Post reply on HN