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

121–130 of 335 posts

Re: Reflections on Distrusting xz

#121

Post by KyleSanderson »

azornathogron wrote: post #49
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…

While it's certainly possible to rewrite git history, it's tricky to do it without other maintainers or contributors noticing, since anyone trying to pull into an existing local repo (rather than cloning fresh) would be hit with an unexpected non-fast-forward merge. It seems likely to me that Lasse Collin would have one or more long-standing local working copies. So IMHO injecting malicious changes back in time in th…

Based on how this has gone (remember xz has effectively been orphaned for years, and the majority of long-standing setups were using the release archives), unless if Lasse has never run any code from Jia (unlikely) I'd consider the entire machine untrusted (keys, etc). Provided the tarballs are still signed from that date, from another immutable source, that's really the only starting point here to rebuilding.

Re: Reflections on Distrusting xz

#122

Post by david_allison »

berkes wrote: post #36
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.

I once got a (probably scam) offer for adding a cryptominer to a library that I maintained at that time. And a more serious offer to add trackers to a popular >1M installs app. Both cases I obviously ignored it. But it made me aware of a nasty attack vector: someone who's thanklessly building a wordpress-plugin, pip, npm, or whatever software, thanklessly dealing with issues, PRs, support, maintainence, often for no…

> suddenly gets offered three figure sums to add a few lines of "affiliate stuff" or such

Back of the envelope calculation: you're looking at 2 orders of magnitude more money from "affiliate stuff" than you would be from generous user donations

Re: Reflections on Distrusting xz

#123

Post by craftkiller »

Lichtso wrote: post #72
AtNightWeCode wrote: post #43

Earlier quoted context omitted.

People think git is immutable. It is not.

Yes and no. A local GIT repo can be changed (including its history) however you please. But once you have shared it with others you can't take that back. If you try to, then others will notice that the hashes mismatch and that their HEAD diffs uncleanly. I know the term is infamous here, but GIT is essentially a blockchain. Each commit has a hash, which is based on the hashes of previous commits, forming a linked lis…

Its a Merkle Tree. They were invented 3 years before blockchains: https://en.wikipedia.org/wiki/Merkle_tree

Re: Reflections on Distrusting xz

#124

Post by MattPalmer1086 »

Y_Y wrote: post #67
andrewinardeer wrote: post #39

Earlier quoted context omitted.

I believe this is a nation state actor and there are a a fleet of 'Jia Tans' working on other OSS projects to backdoor operating systems. And some have probably succeeded.

I believe the term "nation state actor" is a term that means "country" but with the bonus of connoting that the writer is an armchair infosec wizard. This speculation is not valuable without adding information, otherwise it's just McCarthyist bluster.

Nation state actor is a standard info sec term. Using it does not imply any kind of wizardry.

Edit: most threat actors do not have the patience or the motive to behave in this way. It is reasonable to suppose that this is a nation state actor.

Re: Reflections on Distrusting xz

#125

Post by acdha »

arp242 wrote: post #69
irdc wrote: post #52

Earlier quoted context omitted.

At this point, considering the apparent ease with which a project that is used pretty much everywhere was taken over, that seems like a reasonable position.

I can walk out on the street and stab someone to death if I wanted to. This is surprisingly easy. Just because something is relatively easy to pull off doesn't mean it happens a lot. It's also not that easy to pull off because you need to have a project with relatively few eyes and a place to hide it. In this case: binary tests. But most projects don't have those. There is no evidence for any of this, including that…

> There's also a case to be made that it's NOT a nation-state actor as nation states use Linux and want a secure Linux. The NSA and such have somewhat conflicting interests here. We just don't know.

I agree that we do not know that it’s a nation-state but this point seems to work in the opposite direction: this attack was very carefully constructed so only someone with a particular key pair could exploit it. That’s reminiscent of what the NSA did with the Dual EC constants, and they were confident enough about that to push it into the FIPS requirements for federal IT.

Re: Reflections on Distrusting xz

#126

Post by adql »

lispm wrote: post #42

Why not get rid of xz completely? Hoe about using a simpler piece of software, which could be maintained by more people?

> Why not get rid of xz completely?

... you mean compression package used by most big distros to make their packages? Do you really need to ask

> Hoe about using a simpler piece of software, which could be maintained by more people?

It's not a complex piece of software. Lib itself is ~15k lines of code.

It does it's job well and it needs little work. It didn't had any outstanding bugs lingering unfixed for years

Complexity have nothing to do with the problem, it's just... uninteresting enough that there is no reason for contribute.

Re: Reflections on Distrusting xz

#127

Post by [deleted] »

moritonal wrote: post #77
berkes wrote: post #36

Earlier quoted context omitted.

I once got a (probably scam) offer for adding a cryptominer to a library that I maintained at that time. And a more serious offer to add trackers to a popular >1M installs app. Both cases I obviously ignored it. But it made me aware of a nasty attack vector: someone who's thanklessly building a wordpress-plugin, pip, npm, or whatever software, thanklessly dealing with issues, PRs, support, maintainence, often for no…

It's why I actually always encourage app devs to charge for their apps, even open source ones. It creates an exchange of value for the author to feel valued and detract from these vectors.

[deleted]

Re: Reflections on Distrusting xz

#128

Post by strogonoff »

berkes wrote: post #36
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.

I once got a (probably scam) offer for adding a cryptominer to a library that I maintained at that time. And a more serious offer to add trackers to a popular >1M installs app. Both cases I obviously ignored it. But it made me aware of a nasty attack vector: someone who's thanklessly building a wordpress-plugin, pip, npm, or whatever software, thanklessly dealing with issues, PRs, support, maintainence, often for no…

I believe the problem of thankless maintenance is best solved with two things: the thanks (yes, we are all human and want recognition and appreciation from fellow humans)[0], and a stable employment (work for a good large business while open-sourcing what’s possible)[1].

If you do OSS for profit, then it can become a question of where is more money; but if you work a reliable job with insurance, relationships and other implications then the stakes may be a bit different.

Many of the biggest OSS projects today were started by people who had no money in mind whatsoever. Some had other jobs, others were students, etc. If we feel relatively secure, we are driven by our innate desire to tinker, create cool things and show it off.

[0] Undermined by LLMs that are used to gobble up your code and suggest it to others commercially and without attribution.

[1] Undermined by low employment protections (if you can expect to be fired at any time, you would be less loyal), and by LLMs (whatever you open-source now more directly benefits Microsoft or whatever).

Re: Reflections on Distrusting xz

#129

Post by kmfpl »

loftsy wrote: post #86

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…

I agree, this looks extremely sketchy. Especially because the code is just writing a fully controlled byte in the buffer and incrementing its index.

This would give you a controlled relative write primitive if you can repeatedly call this function in a loop and going OOB.

Re: Reflections on Distrusting xz

#130

Post by belorn »

prmoustache wrote: post #78
andrewinardeer wrote: post #39

Earlier quoted context omitted.

I believe this is a nation state actor and there are a a fleet of 'Jia Tans' working on other OSS projects to backdoor operating systems. And some have probably succeeded.

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…

Most of the time they don't need infiltrators. Governments can just pressure companies with export controls or warrantless surveillance to get backdoors into commercial systems. OSS projects require different methods because the more direct method would be discarded by the community and forked.
Post reply on HN