Hacker News new | ask | show | jobs
by tokyobreakfast 110 days ago
> 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.

1 comments

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.
Red Hat noticed that something was off, but there was a new version published by "Jia Tan" that fixed the warnings and the performance issue, so it's not really clear that the original version would have still gotten as deep of an investigation as would have been needed to find the issue.

It's possible though. The noise around it did at least put Freund on alert and we should be very glad both that "Jia Tan" made the mistakes they made originally and that Freund followed up on their gut feeling

The irony being that 'Jia Tan' went out of their way to ensure the backdoor was very well obfuscated, to the point it inadvertently caused bugs and slight, but noticeable, performance issues.

One wonders whether the xz backdoor would have been discovered if slightly less obfuscation was used.

The whole xz incident is a pretty strong argument to:

a) change practice from including binary (opaque) test files themselves to human-readable scripts and tooling that build test files on-demand,

b) raise suspicion of any binaries included in open source projects, and

c) create much more scrutiny around dependencies of 'highly scrutinised' packages like OpenSSH.

It's a shame that there isn't a foundation (that I'm aware of) that can donate time and effort of vetted developers to foundational open source projects like xz.

> create much more scrutiny around dependencies of 'highly scrutinised' packages like OpenSSH.

But xz is not a dependency of upstream OpenSSH you see. It was a dependency of a patch created by Linux distros for systemd integration.

> Red Hat noticed that something was off, but there was a new version published by "Jia Tan" that fixed the warnings and the performance issue

Video of Jia Tan fixing the valgrind bugs: https://www.youtube.com/watch?v=A16YuzuKN58&t=138s

A lot of people fail to fully grasp how bad this could have been on the off chance the authors were slightly less sloppy.
Imo it just proves there's a 99% chance a standard distro has a current zero day in it.

If a state actor (it almost has to be a state actor at the time frame they were operating under) could put in this much effort once, they clearly could afford to do it X times. And when you look through the history of communications from the author, it just reads like 'another day at the office'.

The problem is that there are many many people that are falling over themselves to believe bogus claims about false positives.

Outside of Valgrind bugzilla bug reports these claims almost never stand up to close scrutiny. Not that the people making the claims ever perform any scrutiny. It's usually "my application doesn't crash so it must be a false positive" or "I'm sure that I initialised that variable" or "it's not really a leak, the OS will reclaim the memory".