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

161–170 of 335 posts

Re: Reflections on Distrusting xz

#161

Post by ghaff »

tomn wrote: post #137
brabel wrote: post #50

Earlier quoted context omitted.

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…

Yeah, it's not enforced (and certainly not with linked-in and facebook) but it's really not uncommon to require use of real names for contributions. Linux doesn't allow anonymous contributions: https://www.kernel.org/doc/html/latest/process/submitting-pa... and this guide has been adopted by a lot of GPL-licensed projects (at least openwrt, glibc and gcc).

I'm not sure why the downvotes. That seems to be a statement of fact.

You can do a certain amount of identity obfuscation online but for anyone with a real professional profile you're generally not really anonymous if anyone really cares to find out your true name.

Re: Reflections on Distrusting xz

#162

Post by nottorp »

ghaff wrote: post #151
nottorp wrote: post #115

Earlier quoted context omitted.

I have Facebook and the account and what's on it is no one's -ing business in a professional context.

I wouldn't post anything on Facebook (or on social media generally) that could be professionally embarrassing but I also don't generally accept invites from people who are solely professional acquaintances or use it in a purely professional context at all.

> I wouldn't post anything on Facebook (or on social media generally) that could be professionally embarrassing

The age of self censorship :)

I don't post anything on my FB. I'd still reject any employer who wanted to take a look.

Re: Reflections on Distrusting xz

#163

Post by acdha »

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…

> 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 they're a real person

Have you seen the campaigns people have run building fake LinkedIn profiles and slowly adding “connections”? There was one a few years ago which roped in a lot infosec people who should have known better and it’s gotten much worse with AI generators. Even before LLMs what you described would have been a godsend for intelligence agencies - who has more time for it, an open source developer writing actual code or the dedicated social media team at the IRA? – and now that’s increasingly worse.

Re: Reflections on Distrusting xz

#164

Post by prmoustache »

thewanderer1983 wrote: post #133
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…

Deleted.

The thing is they only need one member sometimes, to observe what is in use.

Example scenario: "malicious engineer in say Microsoft, finds out that office365 is using xz internally and the library is pulled directly without code review. Same engineer or another member of same group would be that Jia Tan doing the necessary backdooring in xz to target office365. And bam all worlwide Office365 accounts would be backdoored."

I am not saying Office365 is using xz, I have no idea really, but this would be a possible scenario. I know MsTeams is using ffmpeg for example.

So I think having this discussion while only scoping linux distributions is a big mistake. xz project was particularly interesting as a target as it is distributed under BSD zero-close license, which is pretty much a public domain license. You don't have the attribution part of the BSD license so there are probably myriads of proprietary software using it too without them acknowledging it.

Re: Reflections on Distrusting xz

#165

Post by Barrin92 »

The_Colonel wrote: post #119
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 this is a nation state actor It is certainly possible, but we don't really have a good indication for that. This whole thing would be definitely doable by a single individual.

doable yes, but what seems to me like a strong indication is the duration, multiple years, and the effort to set up a quasi patch infrastructure for the backdoor which I can't remember ever having seen in some amateur or ransomware hack.

Re: Reflections on Distrusting xz

#166

Post by frankjr »

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.

You're trusting millions of people just to be able to write this comment.

Re: Reflections on Distrusting xz

#167

Post by galangalalgol »

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.

If systemd could deny liblzma any syacall or filesystem access, that would have prevented it. It is only used to compress a data stream, it only needs read access from one buffer, and write access to another. I realize there is no current mechanism for these granular permissions, that is what I was proposing be addressed.

Re: Reflections on Distrusting xz

#168

Post by XorNot »

MattPalmer1086 wrote: post #124
Y_Y wrote: post #67

Earlier quoted context omitted.

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.

There are organised crime networks which buy 0-days to run ransomware, and actively target companies to do it.

Why couldn't this be an attempt at finding or selling exploit access on the black market?

The problem here is no one is looking properly at the scope. It's more then trivial so everyone is leaping for "nation-state" as though that's the only threat actor with motivation and patience.

Re: Reflections on Distrusting xz

#169

Post by coretx »

TeMPOraL wrote: post #112
constantcrying wrote: post #46

Earlier quoted context omitted.

>Are software developers (finally?) going to remove dependencies(now proven to be liabilities!), causing months of refactoring and rewriting, without any other progress? How is that even a possibility? xz was very useful software, which can only exist if people with significant knowledge put effort into it. Not every OSS project has the ability or resources to duplicate that. The same goes for many, many other depend…

Agreed. More than that, there's not much of a way to preven these kinds of attacks, period, whether in software or otherwise, if the perpetrator is some intelligence agency or such. For threats lesser than a black op, the standard way of mitigating supply chain attacks in the civilized world is through contracts, courts, and law enforcement. I could, in theory, get a job at a local food manufacturer, and over the cou…

Code is law. As such, the "standard way" you mention is appropriate for people with zero strategic foresight. There is no absolute need to depend on third parties to solve your problems and the possibility to limit and disperse trust to mostly yourself is real. Sure, glowies can always get to you but they can't get to you everywhere nor all the time. Security/Assurance models and both proprietary and free software architecture are already adapting to such facts.

Re: Reflections on Distrusting xz

#170

Post by cletus »

The US spends $30-60 billion a year on agriculture and subisides [1]. This is controversial for all the obvious reasons. Without subsidies we'd waste less food but overproduction of food is an intentional objective of these programs. Why? Because if there's a major drought or crops are lost to ice or snow or flooding, Americans won't starve. It's why we have things like the US government having a reserve of over a billion pounds of cheese [2].

People not starving is a national security interest.

It's getting to the point where the software we rely on is also a national security interest. The US government should be paying to maintain and improve this software. Security risks in Linux and core packages threaten to shut down key infrastructure.

Paying developers to maintain open source projects that are actually used could be an incredibly effective use of tax dollars.

[1]: https://usafacts.org/topics/agriculture/#581290c9-a960-49aa-...

[2]: https://www.deseret.com/2022/2/14/22933326/1-4-billion-pound...

Post reply on HN