Hacker News new | past | comments | ask | show | jobs | submit login

You can always use the "we have no idea" argument because you can't prove something doesn't exist. Go find evidence. It's been over a month since xz and thus far we have zero additional incidents. And if you look at the specifics of xz attack: that wouldn't work for most projects because most don't have binary test files.



I'm nobody so you have no reason to believe me - but there have indeed been other, very prominent projects targeted in very similar attacks. We're still inside the responsible disclosure window.. hell, even in the blog post we're commenting on, three JS projects were targeted in failed attempts. That's 4 public projects now..


And xz wasn't the first. Several attempts have been made to put garbage in the kernel.


History may record XZ alongside Spectre/Meltdown as industry turning points for "too wide to see".


> three JS projects were targeted in failed attempts.

Suspected to be targetted, in a way that seems to have 0% chance of succeeding for almost any project. Which is why nothing happened.


> seems to have 0% chance of succeeding for almost any project.

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'm not talking about xz, I'm talking about that OpenJS thing: random people emailing out of the blue "plz gimme maintainer". Entirely different situation.

I did quote the "three JS projects were targeted in failed attempts" bit, which should have made that abundantly clear.


Is it a different situation? Seems similar to me, except the examples we know about (the obvious ones) are the low skill examples. If someone played the long game like xz and made some helpful improvements to the project in that time, we wouldn’t know about it.

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!”


Are people really looking though? Are all open source libraries being run through extensive performance profiling to look for known heuristics? Are they being looked at line by line for aberrations?

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.


With hindsight it's not the runtime behaviour of the library that you'd want to test - the weakest point in the chain is where the distributed source .tar.gz can't be regenerated from the project repository.


For how many projects is that actually checked? I bet barely any.

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.


Luckily the source tarball is the more important one to check, because that's the difference between backdooring one distribution and backdooring them all.

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.


It’s worse than that, and that wouldn’t be enough.

A large class of exploitation methods simply have no performance impact.


Most commonly-used projects are watched by a bunch of people, or diffed on updates. These are not in-depth reviews, but should catch most of it. So yes, people are looking, and have been looking for a long time.

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.


Maybe

  // this line is an external audit test - a free gift card to the first person to report finding it.


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

Tools that use LLMs to review code will catch such projects.


No. If there is strong incentive to compromise, and little to no chance a compromise is being found, it's statistically most likely to assume compromises happen on a regular basis and only rarely are found out.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: