3 ms·

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 fa

by arp242 3y ago

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.

Mtinie 3y ago
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.
- arp242 3y ago
  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.
  - caf 3y ago
    Maybe // this line is an external audit test - a free gift card to the first person to report finding it.
  - kjok 3y ago
    > 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.
- caf 3y ago
  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.
  - josephg 3y ago
    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.
    - caf 3y ago
      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.
- BobbyTables2 3y ago
  It’s worse than that, and that wouldn’t be enough. A large class of exploitation methods simply have no performance impact.
mikeyouse 3y ago
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..
- transpute 3y ago
  History may record XZ alongside Spectre/Meltdown as industry turning points for "too wide to see".
- sqeaky 3y ago
  And xz wasn't the first. Several attempts have been made to put garbage in the kernel.
- arp242 3y ago
  > 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.
  - josephg 3y ago
    > 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.
    - arp242 3y ago
      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.
Aerbil313 3y ago
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.

by arp242 3y ago

Mtinie 3y ago

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.

arp242 3y ago
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.
- caf 3y ago
  Maybe // this line is an external audit test - a free gift card to the first person to report finding it.
- kjok 3y ago
  > 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.
caf 3y ago
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.
- josephg 3y ago
  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.
  - caf 3y ago
    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.
BobbyTables2 3y ago
It’s worse than that, and that wouldn’t be enough. A large class of exploitation methods simply have no performance impact.

mikeyouse 3y ago

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

transpute 3y ago
History may record XZ alongside Spectre/Meltdown as industry turning points for "too wide to see".
sqeaky 3y ago
And xz wasn't the first. Several attempts have been made to put garbage in the kernel.
arp242 3y ago
> 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.
- josephg 3y ago
  > 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.
  - arp242 3y ago
    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.

Aerbil313 3y ago

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.