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

151–160 of 335 posts

Re: Reflections on Distrusting xz

#151

Post by ghaff »

nottorp wrote: post #115
ninkendo wrote: post #53

Earlier quoted context omitted.

> 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 Oof, I guess I’m not real then, as I have none of those things.

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.

Re: Reflections on Distrusting xz

#152

Post by rightbyte »

moritonal wrote: post #74
constantcrying wrote: post #62

Earlier quoted context omitted.

>Which raises the concerning question of how much more sleeper maintainers there are. Given how easy the infiltration is and how extremely hard to detect it is, likely a lot. For an intelligence operation it is also extremely cheap, you just need a few knowledgeable developers spending some time each week on the project. The upside being a backdoor into a significant portion of infrastructure, the downside being wast…

The irony is that this would make a oddly effective way of having paid open source devs who for the most part just honestly improve projects. With the massive downside they undermine it at a critical moment.

Ye then maybe thanks to them finally we'll have The year of the air gapped Linux desktop.

I dunno what to do if e.g. Debian gets compromized, as in, I can't trust the collective of maintainers.

I assume any Windows machine is backdoored. Trivially proven by forced auto updates.

Maybe air gapping some home computer for sensitive data might be a good idea.

Re: Reflections on Distrusting xz

#153

Post by lolc »

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…

You're commenting under a link where commits to the xz-decoder are discussed. Some level of paranoia is warranted.

The binary files look like a sideshow in comparison. Maybe we're lucky the attacker was tempted to hide something in there.

Re: Reflections on Distrusting xz

#154

Post by mkj »

galangalalgol wrote: post #76
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

MS funded people and pipelines to analyze it. Jia Tan convinced them to disable the fuzzing that was designed specifically to find malicious behavior, using social engineering, and one MS engineer did find it.

What were the MS analysis projects? The fuzzing was google-sponsored.

Re: Reflections on Distrusting xz

#155

Post by Y_Y »

hyperhopper wrote: post #118
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.

Whales is a country but it is not a nation-state and probably does not have its own APT.

I'll bite. Wales is a country only in a "traditional" sense, since it does not currently hold the type of sovereignty we require of "countries" in the usual sense. As Voltaire said, "This body which called itself and which still calls itself the Holy Roman Empire was in no way holy, nor Roman, nor an empire.".

Wales, when independent, could reasonably be described as a nation state, being roughly associated with the Welsh people and their culture, language, history etc. But most countries are not nation states! The USA, Russia, and China for instance are explicitly plurinational.

If you think "nation" and "state" are synonyms (along with "country") then it's redundant to use both. If you think that "state" alone might lead someone to think of Alabama or Minas Gerais then say "nation". If you think "nation" will make people think of Cherokee, then say "country" or "sovereign state".

"Nation state" has a specific and well-established meaning, misusing it is like misusing any other jargon and just comes across as a failed attempt to seem part of the ingroup and hence authoritative.

(yes, apparently I will die on this hill)

Re: Reflections on Distrusting xz

#156

Post by autoexec »

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…

> 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?

They don't have to sneak into those companies tho, they just hand over something like a national security letter and do whatever they want while making it clear to the heads of the company that anyone who talks or pushes back will rot in gitmo. Why wouldn't there be at least an equivalent to Room 641A (https://en.wikipedia.org/wiki/Room_641A) in every major US corporation that deals with massive amounts of people's sensitive data and communication?

Re: Reflections on Distrusting xz

#157

Post by joeyh »

JoshTriplett wrote: post #10
fsflover wrote: post #7

> What if xz contains a hidden buffer overflow or other vulnerability, that can be exploited by the xz file it's decompressing? If you generalize this problem further, to all packages, then the only reliable solution is security through compartmentalization. On Qubes OS, any file I open, including .jpg and .avi, can't have the access to my private data or attack the admin account for the whole computer. This is ensur…

> the only reliable solution is security through compartmentalization I hope we get there eventually. Not just for standalone processes, but for individual libraries. A decompression library could run inside a WebAssembly sandbox, with the compressed file as input, the uncompressed file as output, and no other capabilities.

Running xz in a sandbox would not prevent an attack that causes it to modify source code in a .tar.xz that is being streamed through it.

Re: Reflections on Distrusting xz

#158

Post by squarefoot »

Maledictus wrote: post #28

Is XZ embedded affected by any of this?

Good question. Embedded systems are harder, sometimes impossible, to upgrade, and there are chances a backdoor in a small board inside an appliance that doesn't offer easy physical access could take years before it is found and removed.

Re: Reflections on Distrusting xz

#159

Post by joeyh »

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…

decompressing gcc.tar.xz which contains foo.png followed by main.c, the decompressor is instructed by the hidden data in the png how to alter the code.

Re: Reflections on Distrusting xz

#160

Post by Macha »

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…

> Are software developers (finally?) going to remove dependencies(now proven to be liabilities!), causing months of refactoring and rewriting, without any other progress?

We've been here before, with e.g. event-stream and colors on npm. So I don't think it will change much. Except maybe people will stop blaming it on JS devs being script kiddies in their mind, when they realise that even the traditional world of C codebases and distro packages are not immune.

Post reply on HN