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

321–330 of 336 posts

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

#321

Post by kzrdude »

nextaccountic wrote: post #210
kzrdude wrote: post #193

Earlier quoted context omitted.

systemd merged a change to using dlopen for compression libraries recently https://github.com/systemd/systemd/pull/31550 which is a safer linking method in that sense.

Why is it safer?

I won't pretend I understand it all, but apart from linking only when needed, some explanations have come out how it would have prevented this exploit path.

From https://research.swtch.com/xz-script

> The effect of the scripts is to arrange for the nefarious object file’s _get_cpuid function to be called as part of a GNU indirect function (ifunc) resolver. In general these resolvers can be called lazily at any time during program execution, but for security reasons it has become popular to call all of them during dynamic linking (very early in program startup) and then map the global offset table (GOT) and procedure linkage table (PLT) read-only, to keep buffer overflows and the like from being able to edit it. But a nefarious ifunc resolver would run early enough to be able to edit those tables, and that’s exactly what the backdoor introduced.

This early execution would not be possible if liblzma was dlopened later.

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

#322

Post by AshamedCaptain »

ycombinatrix wrote: post #320
AshamedCaptain wrote: post #244

Earlier quoted context omitted.

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

i'll take any publicly visible build system over a hidden one

Nothing here was ever hidden.

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

#323

Post by MonkeeSage »

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…

Essentially the code patches ifunc resolvers to call into a supplied malicious object by surreptitiously modifying c files at build time (when ./configure && make is run) and links the compromised object files with a `now` linker flag that causes the ifuncs to be resolved immediately at library load time, which calls the patched resolvers while the process linkage table is still writable, which is the important part that allows them to just hijack the RSA_public_decrypt function in memory when the library is loaded.

There's an excellent technical breakdown of the backdoor *injection process here: https://research.swtch.com/xz-script

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

#324

Post by kuchenbecker »

TacticalCoder wrote: post #228

> Malicious updates made to a ubiquitous tool were a few weeks away from going mainstream. Imagine working, as an individual or as a group, for years and then getting caught mere weeks or months before most major distros were to incorporate your backdoor. Someone or several people out there must be pissed off.

Your implying this is their first Rodeo and don't have others in various stages.

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

#325

Post by hda111 »

red-iron-pine wrote: post #318
acdha wrote: post #240

Earlier quoted context omitted.

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.

SLES is the only real alternative to RHEL for enterprises, also using RPM.

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

#326

Post by ycombinatrix »

AshamedCaptain wrote: post #322
ycombinatrix wrote: post #320

Earlier quoted context omitted.

i'll take any publicly visible build system over a hidden one

Nothing here was ever hidden.

all of Fabrice Bellard's projects are primarily available as tarballs from their website.

definitely more hidden than a public git repo. and allows for xz style backdoors without being able to investigate them after the fact.

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

#328

Post by onoyoudont »

zouhair wrote: post #214
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".

Also, what about those that are not yet discovered?

shh

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

#329

Post by AshamedCaptain »

ycombinatrix wrote: post #326
AshamedCaptain wrote: post #322

Earlier quoted context omitted.

Nothing here was ever hidden.

all of Fabrice Bellard's projects are primarily available as tarballs from their website. definitely more hidden than a public git repo. and allows for xz style backdoors without being able to investigate them after the fact.

I don't see what point you're trying to make. For me a tarball is at least as public as a "public git repo" (whatever that means). In fact I would argue a git repository allows for way more opportunities for obfuscation, seeing that it is a much more complex format.

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

#330

Post by timattrn »

cozzyd wrote: post #266
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…

would it be sufficient to monitor the symbols called by ltrace, somehow?

I wonder about this too, at least in a testing/honeypot build
Post reply on HN