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

221–230 of 336 posts

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

#221

Post by mannyv »

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…

No system is safe from bad actors.

The only way to armor yourself is to have consistent policies. Would this have happened if there were code reviews and testing?

Consistency is key. At my workplace we routinely bypass branch protections, but we're only responsible for a few customers.

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

#222

Post by sargun »

pkulak wrote: post #194
bongodongobob wrote: post #183

Earlier quoted context omitted.

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

To be fair, you also need software engineers to break the windows. It is in our best interest to break the windows.

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

#223

Post by growse »

01HNNWZ0MV43FF wrote: post #212
growse wrote: post #161

Earlier quoted context omitted.

If you actually come from BSD, you'd hopefully recognize a set of different utilities combined to form a holistic system released under a single name. It's not a new idea. Besides, the gpp is incorrect: systemd dependencies are not needed for initialisation notifications.

I think there's a low-effort solution to GP: Just split off the notification function for now. There's a dilemma here: Make a huge number of tiny libraries and people complain about left-pad. Make a monolith and this type of attack can happen. If left-pad is more preventable, let's go that way. The fact that C and C++ have tons of overhead in producing a package is their problem to deal with through better tooling.

> I think there's a low-effort solution to GP: Just split off the notification function for now.

100% agree that some of the functionality could be decoupled, and either the project should provide independent helper libs or at least do a better job of documenting the interfaces.

In this specific case, the notification interface is documented (and there's client implementations in a bunch of languages).

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

#224

Post by edflsafoiewq »

kzrdude wrote: post #193
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.

This hides the dependencies from ldd doesn't it?

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

#225

Post by marcosdumay »

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…

Well, so no news?

But seriously, yes, I think I've seen people dismissing each one of those points. And now we have concrete proof they are real. The fact that somehow an scandal like this didn't happen before due to #1, 2, or 3 is almost incredible... on the meaning that a viable explanation is that somebody is suppressing knowledge somewhere.

Point 8 simply isn't going to happen. And that means that if you want secure OSS, you must pay somebody to look around and verify those things. And the problem with that is this means you are now into the software vendor political dump - anybody that gets big doing that is instantaneously untrustworthy.

Overall, my point is that we need some actual democratic governance on software. Because it's political by nature, and pushing for anarchy works just as well as with any other political body.

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

#226

Post by mrkramer »

CommitSyn wrote: post #142
chpatrick wrote: post #72

Earlier quoted context omitted.

I mean if I was working for a state and had the job of compromising xz that's exactly what I would do.

> Either way, it's your preference and I will follow your lead. Jia Tan > It's out of the scope for this patch, but it is something worth considering. Just trying to do my part as a helper elf! Jia Tan Sounds like someone pulling the strings and using the "it's your idea, I'm just following!" strategy. My hunch from reading over all the language used is that this person spent a good deal of time in America and has a…

>The contributors to this project are hobbyists so we can't dedicate 40+ hours a week for fast releases of high quality. Thank you for your understanding and if you want to help work on anything you can always submit a patch :)

Jia Tan

source: https://www.mail-archive.com/xz-devel@tukaani.org/msg00556.h...

What a guy....he is trying his best to gain people's trust and then shove a backdoor down your throat. And that smiley face at the end is just straight out trolling.

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

#227

Post by jcranmer »

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?

It means the libraries are only loaded when they are needed, so if you never use the (e.g.) xz compression feature, the xz library will not be loaded, and a backdoor added in the xz library simply can't trigger.

(Another side note is this may change the initialization order of libraries--so the initialization functions of an xz library don't run until xz is first used, and this may fail to let you intercept the ssh routines in time.)

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

#228

Post by TacticalCoder »

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

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

#229

Post by marcosdumay »

Karellen wrote: post #155
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…

> 1a. As a consequence of (1) autogenerated artifacts should always be committed. Why don't object files and binaries count as autogenerated artifacts? Should we commit those to the repo too? Where is the line between an artifact that should be committed, and one that shouldn't be? > 4. Libsystemd is a problem for the ecosystem. libc will dynamically load libnss-* on a lot of platforms, some of which can link to a bu…

> Is libc a problem for the ecosystem?

Absolutely yes. And also the size of the kernel.

Those two currently have a much better guaranteed quality than systemd, thus systemd is a much more pressing issue. But they don't stop being a problem just because they are not the largest one.

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

#230

Post by marcosdumay »

hk__2 wrote: post #33
Nullabillity wrote: post #24

Earlier quoted context omitted.

> 1a. As a consequence of (1) autogenerated artifacts should always be committed. Or… just have downstream users run autotools as part of the build?

> Or… just have downstream users run autotools as part of the build? See point 3: > 3. A corollary of (1) and (2) is that autotools is bad and the autotools culture is bad.

Part of the bad in autotools culture is to run it when creating the release so people don't need to run before building.

Letting people run autotools would completely avoid this one hack.

But well, you have a point in that most of what makes autotools bad is that you can't expect your userbase to learn how to use it.

Post reply on HN