6 ms·

I've long since said that if you want to hide something nefarious you'd do that in the GNU autoconf soup (and not in "curl | sh" scripts). Would be interesting

by arp242 3y ago

I've long since said that if you want to hide something nefarious you'd do that in the GNU autoconf soup (and not in "curl | sh" scripts). Would be interesting to see what's going on here; the person who did the releases has done previous releases too (are they affected?) And has commits going back to 2022 – relatively recent, but not that recent. Many are real commits with real changes, and they have commits on some related projects like libarchive. Seems like a lot of effort just to insert a backdoor. Edit: anyone with access can add files to existing releases and it won't show that someone else added it (I just tested). However, the timestamp of the file will be to when you uploaded it, not that of the release. On xz all the timestamps of the files match with the timestamp of the release (usually the .tar.gz is a few minutes earlier, which makes sense). So looks like they were done by the same person who did the release. I suspected someone else might have added/altered the files briefly after the release before anyone noticed, but that doesn't seem to be the case.

sslayer 3y ago
I would be curious if their commits could be analyzed for patterns that could then be used to detect commits from their other account
- deleted 3y ago
  [deleted]
- carom 3y ago
  There was a DARPA program on this topic called Social Cyber. [1] 1. https://www.darpa.mil/program/hybrid-ai-to-protect-integrity-of-open-source-code https://www.darpa.mil/program/hybrid-ai-to-protect-integrity...
- bombcar 3y ago
  One thing that is annoying is that many open source projects have been getting "garbage commits" apparently from people looking to "build cred" for resumes or such. Easier and easier to hide this junk in amongst them.
  - bananapub 3y ago
    annoying ... and convenient for some!
bawolff 3y ago
I mean, a backdoor at this scale (particularly if it wasn't noticed for a while and got into stable distros) could be worth millions. Maybe hundreds of millions (think of the insider trading possibilities alone, not to mention espionage). 2 years doesn't seem like that much work relative to the potential pay off. This is the sort of case where america's over the top hacking laws make sense.
- jethro_tell 3y ago
  And what law would you use to target someone who wrote some code and posted it for free on the internet that was willingly consumed?
  - bawolff 3y ago
    The computer abuse and fraud act? Seems like a pretty easy question to answer.
    - jethro_tell 3y ago
      Maybe I'm miss understanding things, but it seems like anyone can publish an exploit on the internet without being a crime. In the same way encryption is free speech. It would seem unlikely this guy would be also logging into peoples boxes after this. It seems a much tougher job to link something like this to an intentional unauthorized access. At this point, we have no confirmed access via compromise. Do you know of a specific case where the existence of a backdoor has been prosecuted without a compromise? Who would have standing to bring this case? Anyone with a vulnerable machine? Someone with a known unauthorized access. Other maintainers of the repo? IANAL but it is unclear that a provable crime has been committed here
      - refulgentis 3y ago
        > IANAL Best to leave it at that. It's not worth your time or the reader's time trying to come up with a technicality to make it perfectly legal to do something we know little about, other than it's extremely dangerous. Law isn't code, you gotta violate some pretty bedrock principles to pull off something like this and get away with it. Yes, if you were just a security researcher experimenting on GitHub, it's common sense you should get away with it*, and yes, it's hard to define a logical proof that ensnares this person, and not the researcher. * and yes, we can come up with another hypothetical where the security researcher shouldn't get away with it. Hypotheticals all the way down.
eigenvalue 3y ago
Every single commit this person ever did should immediately be rolled back in all projects.
- gopher_space 3y ago
  It's weird and disturbing that this isn't the default perspective.
  - freedomben 3y ago
    Well, it is much easier said than done. Philosophically I agree, but in the real world where you have later commits that might break and downstream projects, etc, it isn't very practical. It strikes me as in a similar vein to high school students and beauty pageant constestants calling for world peace. Really great goal, not super easy to implement. I would definitely be looking at every single commit though and if it isn't obviously safe I'd be drilling in.
  - deleted 3y ago
    [deleted]
  - maxcoder4 3y ago
    Imagine someone tried to revert all the commits you ever did. Doesn't sound easy.
  - concordDance 3y ago
    Some of those commits might fix genuine vulnerabilities. So you might trade a new backdoor for an old vulnerability that thousands of criminal orgs have bots for exploiting. Damage wise, most orgs aren't going to be hurt much by NSA or the Chinese equivalent getting access, but a Nigerian criminal gang? They're far more likely to encrypt all your files and demand a ransom.
    - mysidia 3y ago
      Still.. At this point the default assumption should be every commit is a vulnerability or facilitating a potential vulnerability. For example, change from safe_fprintf to fprintf. It would be appropriate that every commit should be reviewed and either tweaked or re-written to ensure the task is being done in the safest way and doesn't have anything that is "off" or introducing a deviation from the way that codebase standardly goes about tasks within functions.
ptx 3y ago
Couldn't the autoconf soup be generated from simpler inputs by the CI/CD system to avoid this kind of problem? Incomprehensible soup as a build artifact (e.g. executables) is perfectly normal, but it seems to me that such things don't belong in the source code. (This means you too, gradle-wrapper! And your generated wrapper for your generated wrapper. That junk is not source code and doesn't belong in the repo.)
- bonzini 3y ago
  Yes, it's usually regenerated already. However even the source is often pretty gnarly. And in general, the build system of a large project is doing a lot of work and is considered pretty uninteresting and obscure. Random CMake macros or shell scripts would be just as likely to host bad code. This is also why I like meson, because it's much more constrained than the others and the build system tends to be more modular and the complex parts split across multiple smaller, mostly independent scripts (written in Python or bash, 20-30 lines max). It's still complex, but I find it easier to organize.
  - jnxx 3y ago
    > And in general, the build system of a large project is doing a lot of work and is considered pretty uninteresting and obscure. Random CMake macros or shell scripts would be just as likely to host bad code. Build systems can even have undefined behaviour in the C++ sense. For example Conan 2 has a whole page on that.
- mysidia 3y ago
  The other thing besides the autoconf soup is the XZ project contains incomprehensible binaries as "test data"; the "bad-3-corrupt_lzma2.xz" part of the backdoor that they even put in the repo. It's entirely possible they could have got that injection through review, even if they had that framwork and instead put it in source files used to generate autoconf soup.
- WatchDog 3y ago
  gradle-wrapper is just a convenience, you can always just build the project with an installed version of gradle. Although I get your point, it’s a great place to hide nefarious code.
AeroNotix 3y ago
Pure speculation but my guess is a specific state actor ahem is looking for developers innocently working with open source to then strongarm them into doing stuff like this.
- dec0dedab0de 3y ago
  Or hiring them to do it for years without telling them why until they need a favor.
- Bulat_Ziganshin 3y ago
  many people are patriots of their countries. if state agency would approach them proposing to have paid OSS work and help their country to fight terrorism/dictatorships/capitalists/whatever-they-believe, they will feel like killing two birds with one job
  - kelseydh 3y ago
    While this seems plausible, it is notable that this person seems to be anonymous from the get go. Most open source maintainers are proud of their work and maintain publicly available personas.
  - account42 3y ago
    While I don't doubt there are people who would gladly do this work for money/patriotism/whatever, adding a backdoor to your own project isn't really reconcilable with the motivations behind wanting to do OSS work.
bodyfour 3y ago
> I've long since said that if you want to hide something nefarious you'd do that in the GNU autoconf soup (and not in "curl | sh" scripts). Yeah, I've been banging on that same drum for ages too... for example on this very site a decade ago: https://news.ycombinator.com/item?id=7213563 https://news.ycombinator.com/item?id=7213563 I'm honestly surprised that this autoconf vector hasn't happened more often... or more often that we know of.
- pretzel5297 3y ago
  Given that this was discovered by sheer luck, I'd expect way more such exploits in the wild.
dist-epoch 3y ago
> they have commits on some related projects like libarchive Windows started using libarchive to support .rar, .7z, ... https://arstechnica.com/gadgets/2023/05/cancel-your-winrar-trial-windows-will-soon-support-rar-gz-7z-and-other-archives/ https://arstechnica.com/gadgets/2023/05/cancel-your-winrar-t...
IshKebab 3y ago
Yeah this was my first thought too. Though I think the case against autoconf is already so overwhelming I think anyone still using it is just irredeemable; this isn't going to persuade them.
stabbles 3y ago
How about wheels in the python ecosystem
WesolyKubeczek 3y ago
> I've long since said that if you want to hide something nefarious you'd do that in the GNU autoconf soup If I recall correctly, xz can be built with both autoconf and cmake, are cmake configs similarly affected?
- amiga386 3y ago
  Yes, there is evidence of sabotage on the CMake configs too. https://git.tukaani.org/?p=xz.git;a=commit;h=f9cf4c05edd14dedfe63833f8ccbe41b55823b00 https://git.tukaani.org/?p=xz.git;a=commit;h=f9cf4c05edd14de...

by arp242 3y ago

sslayer 3y ago

I would be curious if their commits could be analyzed for patterns that could then be used to detect commits from their other account

deleted 3y ago
[deleted]
carom 3y ago
There was a DARPA program on this topic called Social Cyber. [1] 1. https://www.darpa.mil/program/hybrid-ai-to-protect-integrity-of-open-source-code https://www.darpa.mil/program/hybrid-ai-to-protect-integrity...
bombcar 3y ago
One thing that is annoying is that many open source projects have been getting "garbage commits" apparently from people looking to "build cred" for resumes or such. Easier and easier to hide this junk in amongst them.
- bananapub 3y ago
  annoying ... and convenient for some!

bawolff 3y ago

I mean, a backdoor at this scale (particularly if it wasn't noticed for a while and got into stable distros) could be worth millions. Maybe hundreds of millions (think of the insider trading possibilities alone, not to mention espionage). 2 years doesn't seem like that much work relative to the potential pay off. This is the sort of case where america's over the top hacking laws make sense.

jethro_tell 3y ago
And what law would you use to target someone who wrote some code and posted it for free on the internet that was willingly consumed?
- bawolff 3y ago
  The computer abuse and fraud act? Seems like a pretty easy question to answer.
  - jethro_tell 3y ago
    Maybe I'm miss understanding things, but it seems like anyone can publish an exploit on the internet without being a crime. In the same way encryption is free speech. It would seem unlikely this guy would be also logging into peoples boxes after this. It seems a much tougher job to link something like this to an intentional unauthorized access. At this point, we have no confirmed access via compromise. Do you know of a specific case where the existence of a backdoor has been prosecuted without a compromise? Who would have standing to bring this case? Anyone with a vulnerable machine? Someone with a known unauthorized access. Other maintainers of the repo? IANAL but it is unclear that a provable crime has been committed here
    - refulgentis 3y ago
      > IANAL Best to leave it at that. It's not worth your time or the reader's time trying to come up with a technicality to make it perfectly legal to do something we know little about, other than it's extremely dangerous. Law isn't code, you gotta violate some pretty bedrock principles to pull off something like this and get away with it. Yes, if you were just a security researcher experimenting on GitHub, it's common sense you should get away with it*, and yes, it's hard to define a logical proof that ensnares this person, and not the researcher. * and yes, we can come up with another hypothetical where the security researcher shouldn't get away with it. Hypotheticals all the way down.

eigenvalue 3y ago

Every single commit this person ever did should immediately be rolled back in all projects.

gopher_space 3y ago
It's weird and disturbing that this isn't the default perspective.
- freedomben 3y ago
  Well, it is much easier said than done. Philosophically I agree, but in the real world where you have later commits that might break and downstream projects, etc, it isn't very practical. It strikes me as in a similar vein to high school students and beauty pageant constestants calling for world peace. Really great goal, not super easy to implement. I would definitely be looking at every single commit though and if it isn't obviously safe I'd be drilling in.
- deleted 3y ago
  [deleted]
- maxcoder4 3y ago
  Imagine someone tried to revert all the commits you ever did. Doesn't sound easy.
- concordDance 3y ago
  Some of those commits might fix genuine vulnerabilities. So you might trade a new backdoor for an old vulnerability that thousands of criminal orgs have bots for exploiting. Damage wise, most orgs aren't going to be hurt much by NSA or the Chinese equivalent getting access, but a Nigerian criminal gang? They're far more likely to encrypt all your files and demand a ransom.
  - mysidia 3y ago
    Still.. At this point the default assumption should be every commit is a vulnerability or facilitating a potential vulnerability. For example, change from safe_fprintf to fprintf. It would be appropriate that every commit should be reviewed and either tweaked or re-written to ensure the task is being done in the safest way and doesn't have anything that is "off" or introducing a deviation from the way that codebase standardly goes about tasks within functions.

ptx 3y ago

Couldn't the autoconf soup be generated from simpler inputs by the CI/CD system to avoid this kind of problem? Incomprehensible soup as a build artifact (e.g. executables) is perfectly normal, but it seems to me that such things don't belong in the source code. (This means you too, gradle-wrapper! And your generated wrapper for your generated wrapper. That junk is not source code and doesn't belong in the repo.)

bonzini 3y ago
Yes, it's usually regenerated already. However even the source is often pretty gnarly. And in general, the build system of a large project is doing a lot of work and is considered pretty uninteresting and obscure. Random CMake macros or shell scripts would be just as likely to host bad code. This is also why I like meson, because it's much more constrained than the others and the build system tends to be more modular and the complex parts split across multiple smaller, mostly independent scripts (written in Python or bash, 20-30 lines max). It's still complex, but I find it easier to organize.
- jnxx 3y ago
  > And in general, the build system of a large project is doing a lot of work and is considered pretty uninteresting and obscure. Random CMake macros or shell scripts would be just as likely to host bad code. Build systems can even have undefined behaviour in the C++ sense. For example Conan 2 has a whole page on that.
mysidia 3y ago
The other thing besides the autoconf soup is the XZ project contains incomprehensible binaries as "test data"; the "bad-3-corrupt_lzma2.xz" part of the backdoor that they even put in the repo. It's entirely possible they could have got that injection through review, even if they had that framwork and instead put it in source files used to generate autoconf soup.
WatchDog 3y ago
gradle-wrapper is just a convenience, you can always just build the project with an installed version of gradle. Although I get your point, it’s a great place to hide nefarious code.

AeroNotix 3y ago

Pure speculation but my guess is a specific state actor ahem is looking for developers innocently working with open source to then strongarm them into doing stuff like this.

dec0dedab0de 3y ago
Or hiring them to do it for years without telling them why until they need a favor.
Bulat_Ziganshin 3y ago
many people are patriots of their countries. if state agency would approach them proposing to have paid OSS work and help their country to fight terrorism/dictatorships/capitalists/whatever-they-believe, they will feel like killing two birds with one job
- kelseydh 3y ago
  While this seems plausible, it is notable that this person seems to be anonymous from the get go. Most open source maintainers are proud of their work and maintain publicly available personas.
- account42 3y ago
  While I don't doubt there are people who would gladly do this work for money/patriotism/whatever, adding a backdoor to your own project isn't really reconcilable with the motivations behind wanting to do OSS work.

bodyfour 3y ago

> I've long since said that if you want to hide something nefarious you'd do that in the GNU autoconf soup (and not in "curl | sh" scripts). Yeah, I've been banging on that same drum for ages too... for example on this very site a decade ago: https://news.ycombinator.com/item?id=7213563 https://news.ycombinator.com/item?id=7213563 I'm honestly surprised that this autoconf vector hasn't happened more often... or more often that we know of.

pretzel5297 3y ago
Given that this was discovered by sheer luck, I'd expect way more such exploits in the wild.

dist-epoch 3y ago

> they have commits on some related projects like libarchive Windows started using libarchive to support .rar, .7z, ... https://arstechnica.com/gadgets/2023/05/cancel-your-winrar-trial-windows-will-soon-support-rar-gz-7z-and-other-archives/ https://arstechnica.com/gadgets/2023/05/cancel-your-winrar-t...

IshKebab 3y ago

Yeah this was my first thought too. Though I think the case against autoconf is already so overwhelming I think anyone still using it is just irredeemable; this isn't going to persuade them.

stabbles 3y ago

How about wheels in the python ecosystem

WesolyKubeczek 3y ago

> I've long since said that if you want to hide something nefarious you'd do that in the GNU autoconf soup If I recall correctly, xz can be built with both autoconf and cmake, are cmake configs similarly affected?

amiga386 3y ago
Yes, there is evidence of sabotage on the CMake configs too. https://git.tukaani.org/?p=xz.git;a=commit;h=f9cf4c05edd14dedfe63833f8ccbe41b55823b00 https://git.tukaani.org/?p=xz.git;a=commit;h=f9cf4c05edd14de...