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

231–240 of 336 posts

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

#231

Post by bigbillheck »

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…

> Can’t the OS / environment provide a “features_available”

That wouldn't be consistent with the "unix philosophy".

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

#232

Post by th3typh00n »

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…

> libc is big and complicated and most programs only use a tiny fraction of it. Is libc a problem for the ecosystem?

IMO yes. I definitely believe having basic common functionality (malloc, printf, memcpy etc.) provided by one library with all the crazy/obscure stuff that very few people need or want somewhere else would be an improvement.

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

#233

Post by lenerdenator »

jasode wrote: post #135
aerhardt wrote: post #106

Earlier quoted context omitted.

You could probably get about 80% of the job done with just 20% of the work. I’m not in OSS but I hire technical people remotely, and I know many people that do. Some consultant friends have caught blatant scams within the first couple of rounds of interviews on Zoom.

>I’m not in OSS but I hire technical people remotely, [...] interviews on Zoom. Different situations with different incentives and psychology: - potential to receive money : job candidates are willing to get on Zoom calls or meet in person because they want a paycheck. - no money involved & volunteer for free : potential open source contributors are not interested in getting on Zoom calls for $0 pay.

That's when you dangle a grant in front of them.

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

#234

Post by glenstein »

bombcar wrote: post #176
glenstein wrote: post #121

Earlier quoted context omitted.

And to build on your point (hopefully), one way of understanding #8 is that it's not out of the question that bad actors have the time resource and patience to coordinate long-term campaigns of significant subtlety, the type of which is more easily pulled off by a state actor. Facts such as those should inform our presumptions about when and where people enjoy the benefit of the doubt.

For example, we hope that Linus is not a long-term agent of the Suojelupoliisi - but how would you prove it? Ideally, the "proof is in the code" and the review setup is strong enough that it could handle a Compromised Linus™, even if it couldn't handle multiple compromises.

I mean I would hope that there's a way to separate out the Linuses from the Jia Tans. But it's no longer out of the question that a campaign can build up an account or accounts with long-term histories of good standing that really challenge our intuitions.

But I suppose you are right, the best backstop is for the proof to be in the code.

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

#235

Post by saalweachter »

bogwog wrote: post #71
hk__2 wrote: post #38

Earlier quoted context omitted.

> Is that common to only communicate only through email/github? Yes. I’ve joined half a dozen open-source projects of various sizes (from 100 to 30k stars on GitHub) without ever calling anyone; written communication is the standard.

Sure, but handing over maintainership is a different situation from accepting a few PRs

Have you ever interacted with a volunteer organization?

If you show up for a tea & cookies meet-and-greet and aren't careful, they'll nominate you for chair just because no one else wants it, and "showed up once to a scheduled event" is a higher bar than half the other members have met in while.

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

#236

Post by TacticalCoder »

xyst wrote: post #136

What can be learned here and improve? - systemd and libsystemd is an absolute mess. What are the alternatives at this point? - what processes can be improved for Linux distributions to catch malicious actors trying to push back doors into the ecosystem? - is there a dependency graph that would show how many programs use a specific utility library? Might aid in finding other possible attempts to backdoor

> What can be learned here and improve?

- which firewalling setups would still prevent that exploit from working (like whitelisting IP addresses or blocks allowed to SSH in or, drumroll..., port-knocking).

I don't use port-knocking but now I really wonder what's going to be the argument against port-knocking. Is it really security theatre in the fact of the rube-goldberg too-big-to-ever-be-secure systemd, loading totally unrelated code for a freaking ssh server? This method of operating was just proved to be a security nightmare. And people who are using port-knocking (or IP whitelisting) were/are totally fine versus these kinds of exploits.

So, yup, today I really want to read what people dismissing port-knocking as security theatre have to say (even though I, myself, don't use port-knocking: but I do use IP whitelisting in firewall rules to decide which IPs can SSH in).

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

#237

Post by bongodongobob »

dartos wrote: post #202
bongodongobob wrote: post #179

Earlier quoted context omitted.

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

I mean Okta has shown us that paying for closed source does not imply higher quality or more secure software.

Yeah I'm not implying that's the way to go, but thinking since something open source was compromised that it will encourage businesses to donate is wishful thinking.

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

#238

Post by metalforever »

xyst wrote: post #136

What can be learned here and improve? - systemd and libsystemd is an absolute mess. What are the alternatives at this point? - what processes can be improved for Linux distributions to catch malicious actors trying to push back doors into the ecosystem? - is there a dependency graph that would show how many programs use a specific utility library? Might aid in finding other possible attempts to backdoor

There are a lot of alternatives to systemd

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

#239

Post by metalforever »

looperhacks wrote: post #148
xyst wrote: post #136

What can be learned here and improve? - systemd and libsystemd is an absolute mess. What are the alternatives at this point? - what processes can be improved for Linux distributions to catch malicious actors trying to push back doors into the ecosystem? - is there a dependency graph that would show how many programs use a specific utility library? Might aid in finding other possible attempts to backdoor

> systemd and libsystemd is an absolute mess how? Because they link against a third-party library? > is there a dependency graph that would show how many programs use a specific utility library Agree, important topic > is there a dependency graph that would show how many programs use a specific utility library Depends on the distro, but your package manager should be able to do that. On a global scale, that's likely…

Because its a very large monolithic piece of code, which causes issues with trying to audit it / brings it code that might not be necessary / increases attack surface

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

#240

Post by acdha »

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 RCE would mean anyone who doesn’t have a tightly-restricted network and robust flow logging would struggle to say that they hadn’t been affected.
Post reply on HN