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

Reflections on Distrusting xz

joeyh.name

Post reply on HN
Print view View original

101–110 of 335 posts

Re: Reflections on Distrusting xz

#101

Post by arp242 »

dlandau wrote: post #60
ducktective wrote: post #16

I'm here wondering why big tech companies that have Too Much to Lose didn't already massively fund a project that freaking sshd depended on it (through systemd). Like how does it hurt Google to assign 100 people to review and investigate commits of some project as basic and fundamental as a compression tool

That's exactly what they do, though: https://cloud.google.com/assured-open-source-software/docs

Google also does code reviews for some commonly used projects (or maybe that's part of the same thing? I don't know). I went through that last year with one of my Go libraries.

The idea is good, but the entire process is so bureaucracy-heavy and time-consuming that I found it both frustrating and entertaining in equal parts; like something out of Brazil (the film, not the country). So many emails, so many video meetings, so many people involved, so much talking. And all for looking at a 4,500 line Go library.

"Here's the code; just clone and look at it, and let me know if you find something"... It's not like you need my permission to do any of this *shrug*.

Re: Reflections on Distrusting xz

#102

Post by adql »

rwmj wrote: post #24
gammalost wrote: post #13

Earlier quoted context omitted.

You can't really remove dependencies in open source. It is so intertwined at this point that doing it would be too expensive for most companies. I think the solution is to containerize, containerize and then containerize some more times and make it all with zero trust in mind.

Containerizing is entirely the worst response here. Containers, as deployed in the real world, are basically massive binary blobs of completely uncertain origin, usually hard to reproduce, that easily permit the addition of unaudited invisible changes. (Yes yes, I know there are some systems which try to mitigate this, but I say as deployed in the real world.)

Pretty much; updating say libssl in a "traditional" system running app, or maybe 2-3 dependent apps fixes the bug.

Put all of them in containers and now every single one needs to be rebuilt with the dep fixed and instead of having one team (ops) responsible, you now need to coordinate half of the company to do so. It's not impossible but in general much more complex, despise containers promising "simpler" operations.

...that being said I don't miss playing whack-a-mole game with developers that do not know what their apps need to be deployed on production and for some retarded reason tested their app on unstable ubuntu while all of the servers run some flavour of stable linux with a bit older libs...

Re: Reflections on Distrusting xz

#103

Post by meinersbur »

rkta wrote: post #84
meinersbur wrote: post #37

The greater concern should be how many other sleeper contributors are out there. Anonymous contributions are accepted every day, and we know of cases with malicious intent such by "James Bond" ( https://lore.kernel.org/lkml/20200809221453.10235-1-jameslou... ). I am not specifically worried about other contributions by "Jia Tan", those are being extensively looked at right now. They and other sleepers may just as wel…

What's malicious about that patch? From reading the thread it looks like an attempt to fix a FP from some tooling.

One of the patches that the University of Minnesota was banned for from contributing to the Linux kernel. They were trying to introduce a use-after-free (Fig. 9 in their paper).

https://news.ycombinator.com/item?id=26887670

Re: Reflections on Distrusting xz

#104

Post by adql »

j16sdiz wrote: post #33
moomin wrote: post #27

> Hopefully, Lasse Collin will consider these possibilities and address them in his response to the attack. Here's the thing: Lasse Collin was overloaded back in 2021. I've no particular reason to believe that isn't still the case. He needs help. Dealing with this solo is an incredible amount of work. Also, he needs help from a verifiably trustworthy source, verifiable in a way that doesn't require a lot of effort. I…

... but `xz` is pretty much feature complete to me. Lasse Collin was doing bug-fix-only release just fine.

The start of the attack was few fake accounts trying to shame the maintainer for not "developing" it constantly and so give maintainer rights to someone else.

And there wasn't really anyone to say "nope, it's fine, fuck off"

Re: Reflections on Distrusting xz

#105

Post by j16sdiz »

rfoo wrote: post #47
jwilk wrote: post #32

Earlier quoted context omitted.

I don't think joeyh wanted to imply that PNG uses liblzma. PNG is just a convenient place to put opaque binary stuff that'd trigger an xz compression bug.

I still don't understand how would that work. The post said: > Let's say they want to target gcc. Well, gcc contains a lot of documentation, which includes png images. So they spend a while getting accepted as a documentation contributor on that project, and get added to it a png file that is specially constructed, it has additional binary data appended that exploits the buffer overflow. And instructs xz to modify th…

Consider this backdoor:

- if the decompressed stream contain a magic keyword, run the rest of the file as x86-64 binary.

Now you just need any opaque binary file to host the payload. A PNG works fine, because most decoder don't care extra bytes at the end.

Re: Reflections on Distrusting xz

#106

Post by logro »

iso8859-1 wrote: post #41
logro wrote: post #14

Trusting anything from that actor is full on ignorant, let alone "a new decoder". It's insane.

Trusting people in general is inadvisable. I haven't trusted anyone for years and I am richer than ever.

Those two topic don't have much in common, trusting a state level hacker actor vs. trusting people in general.

Re: Reflections on Distrusting xz

#107

Post by pdimitar »

usefulcat wrote: post #93
pdimitar wrote: post #12

Earlier quoted context omitted.

It's impossible to insure against in any practical terms. The way forward is to invest heavily in a much more security-oriented kernel(s) and make sure that each program has the bare minimum to achieve what it offers as a value-add. The human aspect of vetting seems like an impossibly difficult game of whack-a-mole. Though realistically I doubt that the bad actors have infinite agents everywhere, this also has to be…

> The way forward is to invest heavily in a much more security-oriented kernel(s) While I don't disagree that kernels should be secure, I also don't see how that would have helped in this case, given that (AFAICT) this attack didn't rely on any kernel vulnerabilities..

True, I wasn't specific enough. The attack exploited that nobody thinks security is a serious enough problem. It's a failure of us (the technical community) as a whole, and a very shameful one at that.

Re: Reflections on Distrusting xz

#108

Post by pdimitar »

adql wrote: post #98
galangalalgol wrote: post #90

Earlier quoted context omitted.

Agreed, as a developer: minimize your dependencies while providing your core function. Don't grant dependencies permissions they don't need. Be granular about it. Austral lets you select what filesystem, network, etc. access each library gets. Also, in big organizations, risk assessment is more about making sure there is someone to point the finger at, than actual security. Treating libfubar as golden because it ship…

> Agreed, as a developer: minimize your dependencies while providing your core function. Don't grant dependencies permissions they don't need. Be granular about it. Austral lets you select what filesystem, network, etc. access each library gets. Still wouldn't help for this particular exploit.

Since I didn't keep as current as I wanted to be (work and life happen a lot lately), what could have prevented it?

Re: Reflections on Distrusting xz

#109

Post by simonvc »

adql wrote: post #94
prmoustache wrote: post #78

Earlier quoted context omitted.

I wouldn't limit that to OSS projects. How many of them managed to get hired and are working for Microsoft, Apple, Google, Oracle or Amazon? In some cases they don't even need to introduce backdoors themselves but just review and spot bugs they don't correct or raise issues for but communicate to mothership. They could even work in team with having one building the backdoor and the other approving the code. Most comp…

I'm now imagining a department where every single worker is a spy for different government and they play endless game of "add exploit, close off the other people's exploits". And all of them think they are the 10x developer because all the other people do in their view is pushing shoddy code

I worked on a project just like this once.. a mobile phone network build in the middle east before the arab spring. 10/10 would not repeat the experience.

Re: Reflections on Distrusting xz

#110

Post by nottorp »

brabel wrote: post #50
irdc wrote: post #8

One thing that comes to mind is that “Jia Tan” might be more accurately seen as a “sleeper” of some sort: a foot soldier who infiltrates a juicy open source project and waits for further instructions; backdooring sshd might not have been part of the original plan. Which raises the concerning question of how much more sleeper maintainers there are.

Everyone working on important open source code should have a real identity associated with them. The fact that "Jia Tan" was able to become a maintainer without anyone ever trying to figure out their real identity shows a huge weakness in our trust model in OSS (everyone real would have something like a Linked In page, Facebook, Twitter, Instagram, or better, their own website with stuff that could be used to ensure…

Why would I trust an "important open source project" with my identity?

It goes both ways.

Besides, the 'state actor' the security theater people keep mentioning would have no trouble creating such real identities.

Post reply on HN