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

81–90 of 335 posts

Re: Reflections on Distrusting xz

#81

Post by GoblinSlayer »

rfoo wrote: post #17

Nit-picking but, eh, png does not use lzma at all. > PNG compression method 0 (the only compression method presently defined for PNG) specifies deflate/inflate compression with a sliding window of at most 32768 bytes. Deflate compression is an LZ77 derivative used in zip, gzip, pkzip, and related programs.

The build script decoded a precompiled backdoor code from a binary test file that wasn't really an archive, but encrypted with Caesar cipher. Any blob can be used like this as a trivial steganographic contained.

Re: Reflections on Distrusting xz

#82

Post by craftkiller »

echelon wrote: post #38
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.

We could all be Jia Tan. Someone could be bought, killed and replaced, or simply shadowed when they die or go to jail. Anonymity makes this even easier.

> killed [...] die or go to jail

All of my commits are signed with a PGP key that is on hardware security tokens and password-protected. In the event of my death, my digital identity could not be stolen without backdoors in my hardware security tokens.

That being said, $5 wrenches and large sums of money are still possible attack vectors.

Re: Reflections on Distrusting xz

#83

Post by rfoo »

GoblinSlayer wrote: post #81
rfoo wrote: post #17

Nit-picking but, eh, png does not use lzma at all. > PNG compression method 0 (the only compression method presently defined for PNG) specifies deflate/inflate compression with a sliding window of at most 32768 bytes. Deflate compression is an LZ77 derivative used in zip, gzip, pkzip, and related programs.

The build script decoded a precompiled backdoor code from a binary test file that wasn't really an archive, but encrypted with Caesar cipher. Any blob can be used like this as a trivial steganographic contained.

Any code that extract data from such a blob would look very suspicious.

Re: Reflections on Distrusting xz

#84

Post by rkta »

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.

Re: Reflections on Distrusting xz

#85

Post by the8472 »

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…

If you want security, pay for independent code audits (not compliance bullshit). Repeatedly. Don't offload your desires onto one-man-shows that the world decided are useful tools.

Re: Reflections on Distrusting xz

#86

Post by loftsy »

I took a look at the diff linked in the article with code that "we are all running". The top of the diff certainly looks interesting. They remove the bounds check in dict_put() and add a safe version dict_put_safe().

This kind of change is difficult to make without mistakes because it silently changes the assumptions made when code calling dict_put() was originally written. ALL call sites would need to be audited to ensure they are not overflowing the dictionary size.

The diff I am referring to is here:

https://git.tukaani.org/?p=xz.git;a=commitdiff;h=de5c5e41764...

Re: Reflections on Distrusting xz

#87

Post by rpigab »

What if over 80% of all open source projects are secretly sleeper agents for various malicious actors, states, terrorists and whatnot, and they pretend to give use precious software updates for free so they can attack later?

What if proprietary software is running the same way, except they don't even give you free updates and you can't audit the source code and have to trust them when they push updates?

What if your mother gave birth to you just so she can slap you in the face when you're 30?

Yeah, we can go very far, but in this moment, xz is under so much scrutiny that in 2-4 weeks, I'd trust it with my life unless the big orgs looking at it issue more reverts (hence, the delay). So if there are issues, they're everywhere else.

Re: Reflections on Distrusting xz

#88

Post by rkta »

KyleSanderson wrote: post #31

There seems to be a fundamental misunderstanding with a lot of these writeups. Are they 100% sure history was not rewritten at any point? Going back in time on the repo prior to listed involvement doesn't do anything as the attacker had full control. Starting from the last signed release prior to their involvement is the only way to actually move this forward (history may be fully lost at this point), the rest is pos…

The attacker had access to the GH mirror of the repo. The original repo remained at https://git.tukaani.org/

Re: Reflections on Distrusting xz

#89

Post by dist-epoch »

fl7305 wrote: post #55
KyleSanderson wrote: post #31

There seems to be a fundamental misunderstanding with a lot of these writeups. Are they 100% sure history was not rewritten at any point? Going back in time on the repo prior to listed involvement doesn't do anything as the attacker had full control. Starting from the last signed release prior to their involvement is the only way to actually move this forward (history may be fully lost at this point), the rest is pos…

> Are they 100% sure history was not rewritten at any point? With git, one way to check is if other people still have clones of the xz repository from a time when it was trusted. If you suspect the repo history has been tampered with, you can check against those copies. I believe it would be hard to introduce such a history rewrite, since people pulling from the xz repo would start getting git error messages when thi…

You can create pairs of SHA-1 hash collission, but not for a particular existing SHA-1 hash (the git one)

Re: Reflections on Distrusting xz

#90

Post by galangalalgol »

pdimitar wrote: post #12
berkes wrote: post #2

Full on tinfoil hat here. But warranted and practical. I'm wondering what fallout we'll see from this backdoor in the coming weeks, months or years. Was the backdoor used on obscure build servers or obscure pieces of build infrastructure somewhere? Lying dormant for a moment in future to start injecting code into built packages maybe? Are distro's going to go full-on tinfoil-hat and lock down their distribution, halt…

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…

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 ships with something you paid another company money for makes sense in that light. But not from an actual security mindset.

Post reply on HN