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

What we know about the xz Utils backdoor that almost infected the world

arstechnica.com

Post reply on HN
Print view View original

141–150 of 336 posts

Re: What we know about the xz Utils backdoor that almost infected the world

#141

Post by redserk »

lenerdenator wrote: post #134
redserk wrote: post #109

Earlier quoted context omitted.

It's naive to believe that any form of physical presence means someone isn't going to do something nefarious in the eyes of the project. This problem can only be solved by more skilled eyes on the projects that we rely on. How do we get there? shrug.gif . Anything less is trying to find a cheap and ineffective shortcut in this trust model.

> It's naive to believe that any form of physical presence means someone isn't going to do something nefarious in the eyes of the project. It's not the only thing, but it is something. There's a lot of social engineering that went into the xz backdoor[0]. This started years ago; Jia Tan was posting in projects and suddenly someone appeared to pressure projects to accept their code. Who's Jia Tan? Who's Jigar Kumar, t…

> Having this person or group of people have to continually commit to the bit of publicly-known open-source maintainer who attends conferences,

This is assuming maintainers even care/want to go.

> has an actual face, and is on security camera footage at multiple hotels and airports

The same footage that'll get wiped a few weeks after the conference ends, and quickly becomes not useful.

This is wonderful posturing in the name of security theater but doesn't solve anything.

Re: What we know about the xz Utils backdoor that almost infected the world

#142

Post by CommitSyn »

chpatrick wrote: post #72
mrkramer wrote: post #64

Earlier quoted context omitted.

So did he plan all this from the beginning or somewhere down the line he went full yolo?! I am looking at his mailing chat[0] and he seemed pretty enthusiastic about improving and fixing XZ. [0] https://www.mail-archive.com/search?l=xz-devel@tukaani.org&q...

I mean if I was working for a state and had the job of compromising xz that's exactly what I would do.

> Either way, it's your preference and I will follow your lead. Jia Tan

> It's out of the scope for this patch, but it is something worth considering. Just trying to do my part as a helper elf! Jia Tan

Sounds like someone pulling the strings and using the "it's your idea, I'm just following!" strategy.

My hunch from reading over all the language used is that this person spent a good deal of time in America and has a carefully crafted 'customer service' manner of speaking. I may be wrong on the spending time in America part, but they are most definitely used to putting people at ease with their word choice.

I also found this bit interesting, as it's one of the few times they referred to "us" and "we"

> https://www.mail-archive.com/xz-devel@tukaani.org/msg00644.h...

> Please let us know if there are any concerns about the license change. We are looking forward to releasing 5.6.0 later this month!

Re: What we know about the xz Utils backdoor that almost infected the world

#143

Post by seniorThrowaway »

shrubble wrote: post #111
mrkramer wrote: post #43

At the end of the day, backdoors in the open-source software projects will be caught sooner or later, the problem are backdoors in closed source projects ala NSA backdoors. To this day, I'm not completely sure if my Windows machine is secure or not. I remember Gates once said that governments in the early days of Windows demanded from Microsoft to show them the source code of Windows but even that is not enough since…

Microsoft was the very first to cooperate with the PRISM program...see the 2nd image here https://www.theguardian.com/world/2013/jun/06/us-tech-giants...

Of course MS wants to stay in the good graces of its biggest customer

Re: What we know about the xz Utils backdoor that almost infected the world

#144

Post by xyst »

yosito wrote: post #4

Are we ever going to figure out who Jia Tan is?

To be honest, I’m less worried about the person(s) behind the alias. It can be anybody at this point.

Maybe it’s China? Or maybe it’s Russia using Chinese VPNs and aliases? Oh wait maybe it’s Israel…

These are questions that the political asshats down in Washington DC ask every time shit like this happens. It’s almost always inconclusive.

I would rather focus attention on what can be done to improve software supply chain security.

Re: What we know about the xz Utils backdoor that almost infected the world

#145

Post by kjellsbells »

lenerdenator wrote: post #101
Denvercoder9 wrote: post #93

Earlier quoted context omitted.

> Like, meeting someone at several dev conferences should be a requirement at the very least. This is utterly and completely unfeasible. Most open source maintainers, especially those that are struggling and are pressured to hand-off maintenance, don't have the time, means and will to travel to meet up with prospective co-maintainers, not just once but multiple times. In practice it would just result in projects gett…

Really, it starts before things get bad. This thing where - in the famous XKCD example - a single guy is thanklessly maintaining a project for 20 years in Nebraska needs to stop. Software libraries like these are no longer a one-person job. They can't be for the bus factor alone. Major projects like Linux distros or bigger foundations like Apache or Mozilla need to start harping on people hard to contribute to import…

I think this is a really important point. Every commercial contract I've been involved in has clauses that are intended to mitigate supplier risk, eg that they go out of business, and the contracts people do due diligence on suppliers to vet that they are who they say, try to eliminate the one-person operations, and generally mitigate risk if they really need the code but the only supplier is a tiny startup.

Perhaps large corpos need to apply their standard risk mitigation lens to their supply chain. Their stack or their security depends on these 390 packages. 27 of them have less than 3 maintainers. Recommendation: find alternatives.

Re: What we know about the xz Utils backdoor that almost infected the world

#146

Post by Nullabillity »

simiones wrote: post #86
jorams wrote: post #54

Earlier quoted context omitted.

Whether it's autotools or not is not very relevant to point 1a. I'm also confused why point 1 leads to 1a, and not to the opposite of 1a. Source distribution tarballs should not contain code different from what's in the source repository. They should not contain automatically generated artifacts, since those should not be in the repository, since they are by definition not the source , but output of some kind of buil…

I think the point is that all of the code which will get compiled to produce the final binary should be in the repo, and so any generated code that affects the final binary should be in the repo. The use of autotools or other similar tools, ones that are supposed to generate code on the fly on the final user's machine, make this requirement essentially impossible.

Your compiler also falls under that bucket, though.

Re: What we know about the xz Utils backdoor that almost infected the world

#147

Post by supriyo-biswas »

usrusr wrote: post #103

What I haven't seen discussed much is the linking mechanism that allowed the lib to hook into RSA_public_decrypt. Plenty of talk about what could or could not be achieved by even more process separation and the like, but little about that function call redirect. Could it be possible to establish a way to link critical components like the code for incoming ssh with libraries in some tiered trust way? "I trust you when…

An Erlang actor like model where a program’s sub components call each other by message passing with each having its own security context may work.

However, there are multiple security contexts at play in an operating system; with regards to the XZ backdoor it’s mostly about capability based security at the module level, but you also have capabilities at the program level, and isolation at the memory level (paging), isolation at the micro architectural level, and so on. Ensuring all of these elements work together while still delivering performance seems to be rather challenging, and it’s definitely not possible for the Unix-likes to make a move to such a model because of the replacement of the concept of processes.

Re: What we know about the xz Utils backdoor that almost infected the world

#148

Post by looperhacks »

xyst wrote: post #136

What can be learned here and improve? - systemd and libsystemd is an absolute mess. What are the alternatives at this point? - what processes can be improved for Linux distributions to catch malicious actors trying to push back doors into the ecosystem? - is there a dependency graph that would show how many programs use a specific utility library? Might aid in finding other possible attempts to backdoor

> systemd and libsystemd is an absolute mess

how? Because they link against a third-party library?

> is there a dependency graph that would show how many programs use a specific utility library

Agree, important topic

> is there a dependency graph that would show how many programs use a specific utility library

Depends on the distro, but your package manager should be able to do that. On a global scale, that's likely impossible, because there's no true register of how programs are linked - in fact, the inclusion of libsystemd was distro-specific

Re: What we know about the xz Utils backdoor that almost infected the world

#149

Post by professoretc »

kijin wrote: post #62
EdiX wrote: post #19

My personal takeaways from this: 1. Source distribution tarballs that contain code different from what's in the source repository are bad, we should move away from them. The other big supply chan attack (event-stream) also took advantage of something similar. 1a. As a consequence of (1) autogenerated artifacts should always be committed. 2. Autogenerated artifacts that everyone pagedowns over during code reviews is a…

To clarify (1), we should not be exchanging tarballs, period. Regardless of whether it's different from what's in the source repository. It's 2024, not 1994. If something masquerading as open-source software is not committed to, and built from, a publicly verifiable version-controlled repository, it might as well not exist.

So all of Fabrice Bellard's projects (https://bellard.org/) should not exist?

Re: What we know about the xz Utils backdoor that almost infected the world

#150

Post by pepa65 »

haswell wrote: post #117
AndyMcConachie wrote: post #102

Earlier quoted context omitted.

[flagged]

Let’s step away from the extremist position and there’s an interesting problem underneath. If a company or government organization is hiring engineers who will be responsible for critical code, they will undergo background checks at a minimum to ensure they are not an obvious threat to the organization. This isn’t about “country of origin”, but about the criminal history and ties of the individual regardless of origi…

Anyone that maintains a critical piece of code could get compromised by threats and blackmail, regardless of how clean they were.
Post reply on HN