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

Story of XZ Backdoor [video]

youtube.com

Post reply on HN
Print view View original

41–50 of 55 posts

Re: Story of XZ Backdoor [video]

#41

Post by p0w3n3d »

gopalv wrote: post #35
II2II wrote: post #10

Even though the video is somewhat sensationalized at some points, it is well worth a watch for people who are interested in computers but don't have a background in it. There is a nice mixture of everything from history (e.g. the founding of the FSF) to a clear explanation of a compression algorithm (clear enough that one should be able to implement it). It also makes claims that should make some people stop and thin…

> a clear explanation of a compression algorithm The huffman tree, LZ77 and LZMA explanation is truly excellent for how concise the explanation is. The earlier Veritasium video on Markov Chains in itself is linked if you don't know what a markov chain is. I expected Veritasium to tank when it got sold to private equity & Derek went to Australia, but been surprised to see the quality of the long form stuff churned out…

I liked the presentation about paint mixing, however I think this is not impossible to find the missing key paint having the public paint and the message paint, but still, this is really close to what RSA is

Re: Story of XZ Backdoor [video]

#42

Post by ApolloFortyNine »

tokyobreakfast wrote: post #27
ApolloFortyNine wrote: post #26

Earlier quoted context omitted.

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.

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'.

Re: Story of XZ Backdoor [video]

#43

Post by MzxgckZtNqX5i »

p0w3n3d wrote: post #41
gopalv wrote: post #35

Earlier quoted context omitted.

> a clear explanation of a compression algorithm The huffman tree, LZ77 and LZMA explanation is truly excellent for how concise the explanation is. The earlier Veritasium video on Markov Chains in itself is linked if you don't know what a markov chain is. I expected Veritasium to tank when it got sold to private equity & Derek went to Australia, but been surprised to see the quality of the long form stuff churned out…

I liked the presentation about paint mixing, however I think this is not impossible to find the missing key paint having the public paint and the message paint, but still, this is really close to what RSA is

The paint mixing is actually way closer to the idea of the Diffie-Hellman key exchange, more than RSA.

Re: Story of XZ Backdoor [video]

#44

Post by misswaterfairy »

p0w3n3d wrote: post #41
gopalv wrote: post #35

Earlier quoted context omitted.

> a clear explanation of a compression algorithm The huffman tree, LZ77 and LZMA explanation is truly excellent for how concise the explanation is. The earlier Veritasium video on Markov Chains in itself is linked if you don't know what a markov chain is. I expected Veritasium to tank when it got sold to private equity & Derek went to Australia, but been surprised to see the quality of the long form stuff churned out…

I liked the presentation about paint mixing, however I think this is not impossible to find the missing key paint having the public paint and the message paint, but still, this is really close to what RSA is

I couldn't help but notice it was quite similar to a Numberphile video 8 years earlier...

https://youtu.be/NmM9HA2MQGI

Re: Story of XZ Backdoor [video]

#45

Post by misswaterfairy »

dralley wrote: post #34
ApolloFortyNine wrote: post #26

Earlier quoted context omitted.

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…

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.

Re: Story of XZ Backdoor [video]

#46

Post by tokyobreakfast »

misswaterfairy wrote: post #45
dralley wrote: post #34

Earlier quoted context omitted.

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…

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…

> 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.

Re: Story of XZ Backdoor [video]

#47

Post by TacticalCoder »

Something that's puzzling in that XZ backdoor attempt is that the attacker had to hide the evil payload. And he hid it in test files and AIUI it was injected at build time through a modified build script and that went unnoticed (it's a compiled, deployed, version that got caught by someone and raised alarm bell).

Why are build scripts not operating in a clean directory, stripping away all test related files?

Isn't this something we should begin to consider doing, seen that it's all too easy to put arbitrary things in test files (you can just pretend stuff is "fuzzed" or "random" or "test vectors" and whatnots: there's always going to be room to hide mischief in test files)?

Like literally building, but only after having erased all test directories/files/data.

Or put it this way: how many backdoors are actually live but wouldn't be if every single build was only done after carefully deleting all the irrelevant files related to tests?

Re: Story of XZ Backdoor [video]

#48

Post by ranger_danger »

mc32 wrote: post #9
nerevarthelame wrote: post #5

Earlier quoted context omitted.

Still no smoking gun, but possibly Russia. From the video https://youtu.be/aoag03mSuXQ?t=2883 : > A lot of the aliases, like Jia Tan, they sound like Asian names, and the published changes are all timestamped in UTC+8, Beijing time. So the signs point to China. And that's why it's probably not China. I mean, why would they make it that obvious? Every other part of the operation has been so meticulous, so cautious. >…

Those anecdotes don’t mean anything. If I were China and wanted plausible deniability I would work on CNY and take off on foreign holidays. Of course that leaves Beijing time as a weird oversight though it’s always Beijing time anywhere in China.

One can also make commits with any arbitrary date/time(zone) values they want that don't reflect reality.

Re: Story of XZ Backdoor [video]

#49

Post by paulf38 »

ApolloFortyNine wrote: post #26
tokyobreakfast wrote: post #25

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.

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".

Re: Story of XZ Backdoor [video]

#50

Post by alt227 »

wasting_time wrote: post #39
mbauman wrote: post #6

I'm still floored that Andres both found this and didn't ignore it. It's such a testament to an incredible engineer. (But also, my conspiratorially-inclined mind is quite entertained by the thought of some sort of parallel construction or tip from a TLA.)

With the enormous budgets we allocate in the name of "national security", this is exactly the kind of work I expect TLAs to do. Instead we have come to expect them to cowardly sit on exploits, or actively introduce them, rather than working to secure the general public from adversaries. What a mess.

Wow when you put it like that it really hits hard.
Post reply on HN