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

What we know about the xz Utils backdoor that almost infected the world

arstechnica.com

Post reply on HN
Print view View original

311–320 of 336 posts

Re: What we know about the xz Utils backdoor that almost infected the world

#311

Post by simiones »

Nullabillity wrote: post #146
simiones wrote: post #86

Earlier quoted context omitted.

I think the point is that all of the code which will get compiled to produce the final binary should be in the repo, and so any generated code that affects the final binary should be in the repo. The use of autotools or other similar tools, ones that are supposed to generate code on the fly on the final user's machine, make this requirement essentially impossible.

Your compiler also falls under that bucket, though.

In this case, we're talking about someone distributing source code for others to compile, so that is out of scope.

Re: What we know about the xz Utils backdoor that almost infected the world

#312

Post by auguzanellato »

joveian wrote: post #307
AshamedCaptain wrote: post #69

Why do they say "almost" infected the world? At least 3 quite popular Linux distributions (arch, gentoo, and opensuse tumbleweed) ended up shipping the backdoor _for weeks_ , and it was most definitely working in at least tumbleweed. For weeks! A backdoored ssh! Hardly "almost".

It doesn't seem to have been actually included in the Arch (binary) package but only because the backdoor build system itself didn't include the backdoor for Arch. If you cmp -l liblzma.so.5.6.1 between xz-5.6.1-1 and xz-5.6.1-2 there are only tiny differences. I'm guessing they didn't notice this before writing the advisory. https://github.com/QubesOS/qubes-issues/issues/9067#issuecom...

That’s because one of the first stages of the backdoor, that’s actually running at build time, checks if the distro is DEB or RPM based and aborts otherwise

Re: What we know about the xz Utils backdoor that almost infected the world

#313

Post by xorcist »

paulmd wrote: post #284
xorcist wrote: post #88

Earlier quoted context omitted.

Satire is so hard on the Internet and maybe I'm just thick headed. Just to clarify things, is that a suggestion to shove a JSON parser into either bash or autoconf?

JSON is too far, says the engineering culture still relying on a pile of shell scripts like it’s 1970. (that’s unfair, there’s probably tooling to build the shell scripts automatically I bet)

You have it backwards. The engineering culture that said autoconf increases attack surface, the culture that said that the design of PAM is too complex, that did not accept the patch to link libsystemd to sshd, is the one that constantly tries to avoid unnecessary dependencies.

The engineering culture that non-ironically suggests linking a JSON parser is the culture that disregards the challenges that maintaining dependencies brings.

Yesterday it may have been soups of automatically generated shell scripts, but today it is soups of automatically generated YAML and JSON.

Re: What we know about the xz Utils backdoor that almost infected the world

#314

Post by hackeraccount »

jbritton wrote: post #301

Does anyone know if this has been reported to the FBI and Homeland Security? Or can one just assume they will become aware?

That gets at a question I've wondered about. Is there a crime here? I mean it doesn't seem like the actor broke into a system. What law was broken?

Re: What we know about the xz Utils backdoor that almost infected the world

#315

Post by hackeraccount »

secondcoming wrote: post #30
ChrisMarshallNY wrote: post #22

Earlier quoted context omitted.

If it was state-sponsored (considering the timeline, that's a real possibility), then "Jia Tan" could actually be a collection of folks, working for the same team.

I think 'Jia Tan' is one person who's committing the changes, based on the language used in the commits. Whether those changes came from a group will never be known.

Never say never. There's a paper trail going back a couple of years. People especially professionals can be good with trade craft but everyone makes mistakes.

Re: What we know about the xz Utils backdoor that almost infected the world

#317

Post by browser1 »

usrusr wrote: post #103

What I haven't seen discussed much is the linking mechanism that allowed the lib to hook into RSA_public_decrypt. Plenty of talk about what could or could not be achieved by even more process separation and the like, but little about that function call redirect. Could it be possible to establish a way to link critical components like the code for incoming ssh with libraries in some tiered trust way? "I trust you when…

[dead]

Re: What we know about the xz Utils backdoor that almost infected the world

#318

Post by red-iron-pine »

acdha wrote: post #240
AshamedCaptain wrote: post #69

Why do they say "almost" infected the world? At least 3 quite popular Linux distributions (arch, gentoo, and opensuse tumbleweed) ended up shipping the backdoor _for weeks_ , and it was most definitely working in at least tumbleweed. For weeks! A backdoored ssh! Hardly "almost".

Arch and Gentoo are fairly popular as hobbyist distributions but they’re far less common in professional use, especially for the servers running SSH which this attack targeted. That doesn’t mean what happened is in any way okay but if this hadn’t been noticed long enough to make it into RHEL or Debian/Ubuntu stable you would be hearing about it in notifications from your bank, healthcare providers, etc. A pre-auth RC…

aye, this. RHEL is the industry standard and if you're not using that because you want Enterprise Support than you're using a derivative like Fedora, CentOS, or Rocky. Or else you hang out in the .deb side and use Debian or Ubuntu.

Arch is popular with a niche group of end users, but that ain't what most enterprise architectures are working on.

Re: What we know about the xz Utils backdoor that almost infected the world

#319

Post by andwoe »

heresie-dabord wrote: post #45
EdiX wrote: post #19

My personal takeaways from this: 1. Source distribution tarballs that contain code different from what's in the source repository are bad, we should move away from them. The other big supply chan attack (event-stream) also took advantage of something similar. 1a. As a consequence of (1) autogenerated artifacts should always be committed. 2. Autogenerated artifacts that everyone pagedowns over during code reviews is a…

More personal observations: 8. Consumers are naive, yes. But the software industry itself is naive about the security threat. 9. The social exploit is part of the code exploit. 10. The FOSS axiom "More Eyes On The Code" works, but only if the "eyes" are educated. FOSS needs material support from industry. A MSFT engineer caught this exploit, but it still was released to G.A. in Fedora 41, openSUSE, and Kali . 11. The…

> "More Eyes On The Code" works

That's the whole problem right there: lack of eyes on the code. If this code was actually maintained by more than one person, there's a high chance one of them would have caught on to it.

Re: What we know about the xz Utils backdoor that almost infected the world

#320

Post by ycombinatrix »

AshamedCaptain wrote: post #244
ycombinatrix wrote: post #174

Earlier quoted context omitted.

if these projects have any value, someone will clone them to a public repository.

While introducing minor changes to the build system scripts, you mean?

i'll take any publicly visible build system over a hidden one
Post reply on HN