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

Timeline of the xz open source attack

research.swtch.com

Post reply on HN
Print view View original

341–350 of 482 posts

Re: Timeline of the xz open source attack

#341

Post by orthecreedence »

lr1970 wrote: post #88
lukaslalinsky wrote: post #24

The social side of this is really haunting me over the last days. It's surprisingly easy to pressure people to giving up control. I've been there myself. I can't even imagine how devastating this must be to the original author of XZ, especially if he is dealing with other personal issues as well. I hope at least this will serve a strong example to other open source people, to never allow others to pressure them into…

Look how brilliantly they selected their target project: (1) xz and the lib are widely used in the wild including linux kernel, systemd, openSSH; (2) single maintainer, low rate of maintenance; (3) the original maintainer has other problems in his life distracting them from paying closer attention to the project. I am wondering how many other OSS projects look similar and can be targeted in similar ways?

A takeaway for me is to be extremely tight with personal information on the internet. People will use this to craft a situation to fool you.

Are you married? Have a house? Pets? Children? Sick parent? Gay? Trans? Mental health issues? Disabled? All of this can be used against you. Be careful where and how you share stuff like this. I know it's not "cool" to be mysterious online anymore, but it creates a much larger attack surface. People can still engage with groups around these things, but better to do it with various personas than to have one trackable identity with everything attached to it.

Re: Timeline of the xz open source attack

#343

Post by kashyapc »

oefrha wrote: post #125
kashyapc wrote: post #55

Earlier quoted context omitted.

While "open source" fundamentally doesn't work that way, the point here is about maintainers , not regular contributors. Identity of new maintainers must be vetted (via in-person meetups and whatever other mechanisms) by other "trusted" maintainers whose identities are "verified". I realize, it's a hard problem. (And, thanks for the link to the "Know, Prevent, Fix" post.) PS: FWIW, I "win my bread" by working for a c…

I’ve worked with a few very talented pseudonymous developers on the Internet over the years. I can’t think of any way to vet their identities while maintaining their anonymity (well, it’s basically impossible by definition), plus if you’re talking about in-person meetups, traveling from, say, Asia to North America isn’t cheap and there could be visa issues. The distinction between maintainers and non-maintainers isn’…

You make excellent points; I agree. Especially, a non-maintainer with a high-quality contribution gaining trust. Many times, (tired) maintainers are forced to "rubber-stamp" and merge such high-quality patches. It could be due to any number of (valid) reasons—a CVE fix, an involved performance fix that will take you weeks to load up on the context, enabling a hardware feature that's under semi-NDA, you just trust their work too well, maintainer fatigue, etc.

What I'm saying is, in context of critical-path software, the identity of maintainers vs non-maintainers matters more. I'm not naively claiming that it'll "solve" the problem at hand, just that it's another layer in defense. For a critical software, you shouldn't be able to simply submit a "patch"[1] such as:

  tests: Add-binary-blob-with-a-subtle-backdoor.xz

  Signed-off-by: "Anonymous Rabbit"
Commit it yourself, brazenly push it into Linux distros, and then anonymously sign off into the sunset with no trace. I'm sure you'll agree that there's a world of difference between a deeply entrenched, critical libray and a random user-space application.

It's a messy situation. How much, if at all, "clever tech" can mitigate this human "trust issue" is an open problem for now.

[1] https://git.tukaani.org/?p=xz.git;a=commitdiff;h=cf44e4b7f5d

Re: Timeline of the xz open source attack

#344

Post by cesarb »

kjellsbells wrote: post #333
mseepgood wrote: post #7

Never allow yourself to be bullied or pressured into action. As a maintainer, the more a contributor or user nags, the less likely I am to oblige.

True, but a determined adversary like JiaTan/Jugar has an ace up their sleeve: they are good enough, and patient enough, to be able to fork the base project, spend a year or two making it better than the original (releasing the head of steam built up from legitimate requests that the old, overworked maintainer never got too, building goodwill in the process) and then convincing the distros to pick up their fork inste…

> and then convincing the distros to pick up their fork instead of the older original.

Given the current situation, I'm slightly worried about Fedora's planned move to zlib-ng instead of zlib in the next release (https://fedoraproject.org/wiki/Changes/ZlibNGTransition).

Re: Timeline of the xz open source attack

#346

Post by dist-epoch »

kevindamm wrote: post #134
dist-epoch wrote: post #104

Earlier quoted context omitted.

Remote code execution already implies unauthorized. There is no such thing as authorized remote code execution.

What makes you say that? SSH, RDP, even hitting a web service are all valid cases of authorized remote code execution. It's not the remote or execution parts that are bad.

Now you're redefining words.

Remote code execution means a single thing, running JavaScript when accessing a web page and using SSH as intended is not RCE.

https://en.wikipedia.org/wiki/Remote_code_execution

https://www.google.com/search?q=Remote+code+execution

Re: Timeline of the xz open source attack

#347

Post by tadfisher »

comex wrote: post #286
wongarsu wrote: post #241

Earlier quoted context omitted.

Most of these could still be covered with IO limited to the project files though. There is a sizable movement in the Rust ecosystem to move all build-time scripts and procedural macros to (be combined to) WASM. This allows you to write turing-complete performant code to cover all use-cases people can reasonably think of, while also allowing trivially easy sandboxing. It's not perfect, for example some build scripts d…

But the xz backdoor didn’t involve a build script that tried to compromise the machine the build was running on. It involved a build script that compromised the code being built. Sandboxing the build script wouldn’t have helped much if at all. Depending on the implementation, it might have prevented it from overwriting .o files that were already compiled, maybe. But there would still be all sorts of shenanigans it co…

Ultimately you're going to have to be adept at stuff like the Underhanded C Contest to spot this kind of thing in any Turing-complete language, so the idea of auditing the source is unreliable at worst. So I'd take another page from the Java/Maven ecosystem and require hashed+signed binaries, with the possible addition of requiring builds to be performed on a trusted remote host so that at least we can verify the binary is produced from the same source and results in the same output.

But determined actors with access are always going to try to thwart these schemes, so verification and testing is going to need to step up.

Re: Timeline of the xz open source attack

#348

Post by kevindamm »

dist-epoch wrote: post #346
kevindamm wrote: post #134

Earlier quoted context omitted.

What makes you say that? SSH, RDP, even hitting a web service are all valid cases of authorized remote code execution. It's not the remote or execution parts that are bad.

Now you're redefining words. Remote code execution means a single thing, running JavaScript when accessing a web page and using SSH as intended is not RCE. https://en.wikipedia.org/wiki/Remote_code_execution https://www.google.com/search?q=Remote+code+execution

I may not have been clear -- I agree that RCE, unqualified, means unauthorized RCE. but then you said there was no such thing as an "authorized" RCE and that's where I beg to differ. Sure, the term isn't used much but it wasn't the clarifying point I wanted to make above, that there is a difference between authenticated and authorized.

The links you point to there are about "RCE attack" which also implies not authorized.

Re: Timeline of the xz open source attack

#349

Post by Vegenoid »

dylan604 wrote: post #161
phicoh wrote: post #94

Earlier quoted context omitted.

I think a problem is that there doesn't seem any way to automatically check this. If we assume that anything that is used during build time can be malicious then figuring out those dependencies is already hard enough. Mapping that to organizational stability is one step further.

This is where the but FOSS is reviewable so it is trusted falls down. This situation is a prime example of how that fallacy is misconstrued. By being FOSS didn't make it trustworthy, it just meant that people had a fighting chance to find out why when something does happen. That's closing the barn door after the horses already left. I'm not knocking FOSS at all. I just think some people have the concept twisted. Just…

> That's closing the barn door after the horses already left.

I don't think that's quite true - maybe a couple horses got out, but this was caught early and did not get to infect very many machines because someone completely unaffiliated could review it and find it.

Re: Timeline of the xz open source attack

#350

Post by kashyapc »

cesarb wrote: post #142
oefrha wrote: post #125

Earlier quoted context omitted.

I’ve worked with a few very talented pseudonymous developers on the Internet over the years. I can’t think of any way to vet their identities while maintaining their anonymity (well, it’s basically impossible by definition), plus if you’re talking about in-person meetups, traveling from, say, Asia to North America isn’t cheap and there could be visa issues. The distinction between maintainers and non-maintainers isn’…

> traveling from, say, Asia to North America isn’t cheap and there could be visa issues. And there are other reasons some people might not want to travel outside their nearby region. For instance, they might be taking care of an elderly relative. Or they might be the elderly relative, with travel counter-indicated for health reasons.

I agree, these are all really valid reasons. FWIW, I myself have worked with "anonymous" maintainers and contributors that I've never met.
Post reply on HN