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

191–200 of 336 posts

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

#191

Post by jerf »

bongodongobob wrote: post #179
markus_zhang wrote: post #170

Earlier quoted context omitted.

I hope Open Source maintainers and the big companies get the message -- they need to change the financial outlook of open source maintaining.

I think the message would more likely be "don't use open source and pay for closed source" than "give money to open source and cross your fingers that it does something".

If that is the takeaway the industry takes from this, it will be a huge mistake. We are talking about this at all precisely because it was open source. Commercial closed source software can simply be assumed to be compromised. We know of enough instances of it happening that if you still have a knee-jerk "oh that sounds like a conspiracy theory" reaction to that claim, you need to recalibrate your conspiracy theory meter, quickly.

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

#192

Post by jerf »

Denvercoder9 wrote: post #93
lenerdenator wrote: post #90

Earlier quoted context omitted.

I think you could interpret this as "you need to know, personally, the party you're handing this off to, and make reasonable judgments as to whether or not they could be easily compromised by bad actors". Like, meeting someone at several dev conferences should be a requirement at the very least.

> Like, meeting someone at several dev conferences should be a requirement at the very least. This is utterly and completely unfeasible. Most open source maintainers, especially those that are struggling and are pressured to hand-off maintenance, don't have the time, means and will to travel to meet up with prospective co-maintainers, not just once but multiple times. In practice it would just result in projects gett…

Intelligence agencies mastered fooling people about their bona fides in person a long time ago. Meeting someone in person will stop casual individuals who just want to crash the project for the lols or some other personal-level reason, but it would have been barely a bump in the road for this clearly-nation-state-level attack.

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

#193

Post by kzrdude »

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…

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.

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

#194

Post by pkulak »

bongodongobob wrote: post #183
markus_zhang wrote: post #181

Earlier quoted context omitted.

Either way, it gives more jobs and $$$ to software developers in general. I'm fine with both :) Just imagine how many more jobs will be created if every large company decides to roll their own stuffs. A lot are actually doing this, but not enough.

That just sounds like the broken window fallacy then. "It's good we have broken windows so the window makers have jobs".

It absolutely is. But we're all window makers, so our perspective is slightly different from general econ. ;)

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

#195

Post by lenerdenator »

redserk wrote: post #141
lenerdenator wrote: post #134

Earlier quoted context omitted.

> It's naive to believe that any form of physical presence means someone isn't going to do something nefarious in the eyes of the project. It's not the only thing, but it is something. There's a lot of social engineering that went into the xz backdoor[0]. This started years ago; Jia Tan was posting in projects and suddenly someone appeared to pressure projects to accept their code. Who's Jia Tan? Who's Jigar Kumar, t…

> Having this person or group of people have to continually commit to the bit of publicly-known open-source maintainer who attends conferences, This is assuming maintainers even care/want to go. > has an actual face, and is on security camera footage at multiple hotels and airports The same footage that'll get wiped a few weeks after the conference ends, and quickly becomes not useful. This is wonderful posturing in…

> This is assuming maintainers even care/want to go.

If they don't want to go, don't use their project. Sorry, these aren't the TI-83 games you passed around at your high school with programming cables; they're the code libraries our society is built on. If my project relies on your project, I need to know who you are. If I can't figure that out, I'll try to find another one.

> The same footage that'll get wiped a few weeks after the conference ends, and quickly becomes not useful.

This is wonderful posturing in the name of security theater but doesn't solve anything.

Along with receipts, eyewitnesses, plane tickets, etc. that put a person at a place at a time. Doesn't all have to be digital evidence.

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

#196

Post by lenerdenator »

markus_zhang wrote: post #190
lenerdenator wrote: post #178

Earlier quoted context omitted.

Sounds like it's time for someone to either pay a few visits to the remote maintainer or give them a scholarship for attending a few conferences.

The big companies can do that. But then there is also the question of -- how many of these critical OS libraries are there in the wilderness?

I feel a census coming on.

There needs to be a reckoning of who is doing what where on this sort of thing. After this whole fiasco you'll probably see more contracts wanting to know who's working on these things, and that will, in turn, have people auditing their software's packages.

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

#197

Post by kuschku »

xorcist wrote: post #139
kuschku wrote: post #61

Earlier quoted context omitted.

libsystemd had already removed the lzma dependencies last week, before the backdoor became public, to reduce external dependencies.

No they did not. The dependency is still there, it's just being lazy loaded. This would be prevented this particular exploit, which would have needed to take another approach, but at the price of making dependencies invisible and hard to debug. You could no longer have found vulnerable systems by way of ldd. The only solution for the attack surface of systemd is to make the individual components more loosely coupled.…

Even if it hadn't been loaded by libsystemd, liblzma is also loaded by SELinux, which would have allowed the same vulnerability via a different vector.

Personally I think projects like fedora silverblue/kinoite and other container-based OSes are going in the right direction. We need a base OS that's as small as possible so it can be audited, and everything else then needs to live in a container so it doesn't have to be audited but is still secured properly.

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

#198

Post by clnhlzmn »

lenerdenator wrote: post #90
Denvercoder9 wrote: post #81

Earlier quoted context omitted.

> 8. This sucks to say, but code reviews and handing off maintainership, at the moment, need to take into account geopolitical considerations. That won't help. There's no evidence that Jia Tan is a real name, or even a real person for that matter. If projects stop accepting contributions from asian-sounding names, the next attack will just use Richard Jones as a name.

I think you could interpret this as "you need to know, personally, the party you're handing this off to, and make reasonable judgments as to whether or not they could be easily compromised by bad actors". Like, meeting someone at several dev conferences should be a requirement at the very least.

This is really not the responsibility of unpaid developers.

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

#199

Post by jcranmer »

josephg wrote: post #53
disconnect3d wrote: post #23

Earlier quoted context omitted.

I would personally add: test your build scripts. There are so many bugs like the "added dot to disable landlock" added as part of this action (which can also be typos [0]), not to mention that relying on some tools in autoconf to set feature flags will just disable them if those tools are not present [1]. [0] https://twitter.com/disconnect3d_pl/status/17744965092596453... [1] https://twitter.com/disconnect3d_pl/statu…

I don’t understand how this is still the best way to test if features are available in C. Can’t the OS / environment provide a “features_available” JSON blob listing all the features on the host system? Is AVX2 available on the cpu? OpenSSL? (And if so, where?) and what about kernel features like io_uring? Doing haphazard feature detection by test compiling random hand written C programs in a giant sometimes autogene…

A few things here.

First, yes, there's several tools which provide (incomplete) feature selection functionality, you can see some sibling comments for examples.

Second, especially in complex projects, the presence of a feature doesn't necessarily mean it's sufficiently complete to be workable. You can run into issues like, say, "I need io_uring, but I need an io_uring op added in version X.Y and so it's not sufficient to say 'do I support io_uring.'" Or you can run into issues like "this feature exists, but it doesn't work in all cases, particularly the ones I want to use it for."

Third, there's no real alternative to feature detection. In practice, build systems need to cope with systems that pretend to be other systems via incompletely-implemented compatibility layers. Version detection ends up creating the User-Agent problem, where every web browser pretends to be somebody pretending to be somebody pretending to be Netscape 5.x and if you try to fix this, the web breaks. (Not to mention the difficulty of sniffing versions correctly; famously, MS skipped Windows 9 reportedly because too many build systems interpreted that to mean Windows 95 or Windows 98 with catastrophic results).

The end result of all of this is that the most robust and reliable way to do feature detection is to try to use the feature and see if it works.

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

#200

Post by levi_n »

Im curious as to why they picked the commit cadence they did. Why do this over the course of two years and not, say 8 months or 15 months? After committing the first patch, why did they wait x days/weeks/months to commit the second? Were they timing the commits off of release schedules, following some predetermined schedule, or something else?
Post reply on HN