[flagged]
We literally have no idea how many xz-style compromises are out there in the wild. We got really lucky with xz - it was only found because the backdoor was sloppy with performance and a microsoft employee got curious. But we have no data on all the times we got unlucky. How many packages in the linux ecosystem are compromised in this way? Maybe none? Maybe lots? We just don't know.
I'm sure any binary blobs in OSS software, no matter what the reason for having them will be viewed with suspicion, and build scripts get extra inspection after that.
Maybe I'm naive in thinking that some people are already looking into packages that are included in all base Linux builds? Including simplifying the build env, and making sure that the the build tools themselves (cmake, pkgconfig, gmake, autotools etc) are also not compromised.
Suspected to be targetted, in a way that seems to have 0% chance of succeeding for almost any project. Which is why nothing happened.
Its obviously more than 0% given xz was successfully taken over and backdoored. Even a 5% chance of malicious takeover per project would make the situation pretty worrying given how many well funded, motivated government agencies are out there.
I did quote the "three JS projects were targeted in failed attempts" bit, which should have made that abundantly clear.
People have also done the same thing (to great effect) on the chrome extension “store” to get all manner of malware into chrome extension updates.
“Nobody unsubtle was successful” tells us nothing about the success rate of subtle attackers. It’s like looking at all the dodgy ssh and http requests any host on the internet is connected to and concluding “yep, 0% of low effort script kiddie attacks get through. I’m 100% safe from hackers!”
I don’t have confidence that people are looking for evidence of potential exploitation because of reasons like the ones you bring up.
So we’re back to we just don’t know.
Its especially difficult because most projects aren't built in a reproducible way. You should be able to uncompress and compare a source tarball. But if you get a binary and the source code used to generated that binary, there's no way to tell that they match.
It's still not trivial because there might well be legitimate processing steps that are used to create the tarball, but it should be doable.
A large class of exploitation methods simply have no performance impact.
The reason Jia Tan could do their thing is because 1) the main meat was in a binary test file, 2) the code to use that seemed relatively harmless at a glance, and 3) people were encouraged to use the .tar.gz files instead of git clone. Also you need to actual get maintainer status, which is not as easy as it sounds.
I've been thinking of inserting a "// THIS LINE IS MALICIOUS, PLEASE REPORT IF YOU SEE IT" in some of my projects to see how long it would take. I bet it would be pretty fast either after commit or after tagging a release.
// this line is an external audit test - a free gift card to the first person to report finding it.Tools that use LLMs to review code will catch such projects.
Why not be curious rather than just dismissive? This seems to be people just talking past each other at this point.
There have been a lot of changes in the last ~five years that point in the direction of supply chain security being at greater risk.
Evidence comes in many forms. The relevance of evidence depends on what part of the problem you are looking at.
Also, it is rational to talk about the probability by which different evidence is likely to be surfaced!
I think it is possible you are sensitive to people making such claims for self-interested purposes. Fair? But I don’t think it’s fair to assume that of commenters here.
Yeah, you're probably not wrong. I've had this argument a few times now, and it's the same dismissive "we don't know what we don't know" every time. Well, you can say that for everything and given the complexities of the xz attack that seems a bit unlikely to me, which is then again countered with "but we don't know!!11"
"Every contributor is dangerous" is spectacularly toxic type of attitude. I've already seen random people be made a target and even had their employers contacted over this before they even had a chance to explain(!!) To say nothing of "there are many ways to compromise existing maintainers. Compromising people is the core competency of intelligence, happens all the time" – so great, now I'm also potentially dangerous after spending untold hours and money over the last 20 years because I could be compromised. Great.
This was never a nuanced conversation about risk management to start with. This is not the type of community I've worked for all this time. "Let's use some common-sense tech so this isn't that easy". Sure, let's talk about that. "Let's treat every volunteer involved as potentially hostile and compromised after we've seen a single incident"? Yeah, nah.
> "Every contributor is dangerous" is spectacularly toxic type of attitude.
I view this from the lens of "How well can people reason about probabilities?" and research has shown, more or less, "not very well". In the short term, therefore, it is wise to tailor communications so as to avoid predictable irrational reactions. In the medium term, we need to _show_ people how to think about these questions rationally, meaning probabilistically.
For what it is worth, I prefer to avoid using the phrase "common sense", as it invites so many failure modes of thinking.
My current attitude is, more or less, "let's put aside generalizations and start talking about probabilities and threat models". This will give us a model that makes _probabilistic predictions_. Models, done well, serve as concrete artifacts we can critique and improve _together_.
I hope to see some responses to my other comment at https://news.ycombinator.com/item?id=40271146 but I admit it takes more effort to share a model. It is well outside the usual interaction pattern here on HN to make a comment with a testable prediction, much less a model for them! Happily, there are online fora that support such norms and expectations, such as LessWrong. But I haven't given up hope on HN, as it seems like many people have the mindset. I think the social interaction pattern here squanders a lot of that individual intelligence, unfortunately... but that pattern can change in a bottom-up fashion as people (more or less) demand, at the very least, clearer explanations.
Every pilot in the world will agree that we need to think about risk management to prevent that sort of thing. I think a lot of them will have issues if we start saying things like "every pilot is dangerous" and (in a follow-up) "long-term good faith pilots are maybe even more dangerous than new maintainers". Then you've gone from "risk management" to just throwing shade.
What should professionals in cybersecurity do? (Not my field, so I could be off-target here) My recommendation: communicate a risk model [1], encourage people to update it for their situation, and demand that people act on it [2]. Not too different from what the field of cybersecurity recommends now. (Or am I wrong?)
[1] based on a set of attack trees (right?)
[2] based on the logic that if you get pwned, you become a zombie to attack me
I'm not quite following the second sentence. What kind of community have you worked for? Do you mean "worked for" as in e.g. "the spirit of your comments on HN"? Or something else?
But yes, that's what I meant, roughly.
The attack itself is the frankly evidence. It’s sort of like how we expect there to be life on other planets because there is life on earth.
I understand being wary of America trying to solve this the only way we know how (PRIVATIZE IT!), but dismissing it as a non-issue makes that more likely because you're basically saying you plan on ignoring it rather than putting your own controls in place.
Yes, FOSS projects need to be welcoming to new devs. No, they don't need to pretend malicious actors aren't an issue in order to do that.
You can vet new people, and be welcoming, at the same time.
This is specious reasoning.
You're only complaining you only heard of two incidents.
What you're really pointing out is that this attack vector works reliably well and is reproducible across projects.
You're also pointing out that this attack vector will continue to work until something is done to mitigate it.
I really do not understand what point you think you are making.
And by the way, stabbings happen all the time, at least 3 per day. Stabbings hurt a few people, cybersecurity incidents can hurt millions.
I've been pretty clued up on open source for the last 20 years, and I don't really recall any other similar incidents other than the two I mentioned. I tried to find other examples a few weeks ago and came up empty-handed. It's certainly not common. So please do post specifics if you know of additional incidents, because from what I can see, it's exceedingly rare.
I'm not confident about anything, but anything could happen or have happened all the time. We need to operate on the reality that exists, not the reality that perhaps maybe possibly could perhaps maybe possibly exist. And we certainly shouldn't be treating anyone sending you a patch as a dangerous hostile actors by default.
If someone is getting angry that you actually check their code for vulns, or that you don't let them make changes to certain core areas of a large app without establishing some credibility first, you probably don't want them working on your project.
You can be welcoming AND cautious at the same time.
It literally just happened.
And no, being cautious is never throwing shade, unless you're doing it in a discriminatory way, like assuming that Chinese or Russian contributors are more dangerous.
> social engineering
The best bugdoors are deniable.