I would definitely be looking at every single commit though and if it isn't obviously safe I'd be drilling in.
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.
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.
A lot of eyes are on the code. From all sides. Folks trying to find old unpatched backdoors to exploit or patch.
randomly reverting two years of things across dozens of repositories will break them, almost definitely make them unbuildable, but also make them unreleasable in case any other change needs to happen soon.
all of their code needs to be audited to prove it shouldn't be deleted, of course, but that can't happen in the next ten minutes.
I swear that HN has the least-thought-through hot takes of any media in the world.
The irony is too good.
for commit in author_commits
git revert $commitSlight oversimplification, see https://bugs.debian.org/1068024 discussion.
(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.)
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.
Build systems can even have undefined behaviour in the C++ sense. For example Conan 2 has a whole page on that.
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.
Easier and easier to hide this junk in amongst them.
1. https://www.darpa.mil/program/hybrid-ai-to-protect-integrity...
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
I'm honestly surprised that this autoconf vector hasn't happened more often... or more often that we know of.
This is the sort of case where america's over the top hacking laws make sense.
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
Of course. The mere publishing of the exploit is not the criminal part. Its the manner & intent in which it was published that is the problem.
> At this point, we have no confirmed access via compromise.
While i don't know the specifics for this particular law, generally it doesn't matter what you actually did. What is relavent is what you tried to do. Lack of success doesn't make you innocent.
> Who would have standing to bring this case?
The state obviously. This is a criminal matter not a civil one. You don't even need the victim's consent to bring a case.
[IANAL]
See for example page 35 in the Justice Department’s computer crimes handbook (dated, but basically AIUI the same way they still do things) [0]
[0] https://www.justice.gov/d9/criminal-ccips/legacy/2015/01/14/...
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.
1. It should be legal to develop or host pen-testing/cracking/fuzzing/security software that can break other software or break into systems. It should be illegal to _use_ the software to gain _unauthorised_ access to others' systems. (e.g. it's legal to create or own lockpicks and use them on your own locks, or locks you've been given permission to pick. It's not legal to gain unauthorised access _using_ lockpicks)
2. It should be illegal to develop malware that _automatically_ gains unauthorised access to systems (trojans, viruses, etc.). However, it should be legal to maintain an archive of malware, limiting access to vetted researchers, so that it can be studied, reverse-engineered and combatted. (e.g. it's illegal to develop or spread a bioweapon, but it's ok for authorised people to maintain samples of a bioweapon in order to provide antidotes or discover what properties it has)
3. What happened today: It should be illegal to intentionally undermine the security of a project by making bad-faith contributions to it that misrepresent what they do... even if you're a security researcher. It could only possibly be allowed done if an agreement was reached in advance with the project leaders to allow such intentional weakness-probing, with a plan to reveal the deception and treachery.
Remember when university researchers tried to find if LKML submissions could be gamed? They didn't tell the Linux kernel maintainers they were doing that. When the Linux kernel maintainers found out, they banned the entire university from making contributions and removed everything they'd done.
https://lkml.org/lkml/2021/4/21/454
https://arstechnica.com/gadgets/2021/04/linux-kernel-team-re...
No, people being polite and avoiding the more direct answer that'd make people feel bad.
The rest of us understand that intuitively, and that it is already the case, so pretending there was some need to work through it, at best, validates a misconception for one individual.
Less important, as it's mere annoyance rather than infohazard: it's wildly off-topic. Legal hypotheticals where a security researcher released "rm -rf *" on GitHub and ended up in legal trouble is 5 steps downfield even in this situation, and it is a completely different situation. Doubly so when everyone has to "IANAL" through the hypotheticals.
This is not unauthorized access, but is also clearly wrong. I'm wondering if its illegal, or if its unauthorized access . . .
Also, I think getting malicious code into a repo counts as a compromise in and of itself.
Windows started using libarchive to support .rar, .7z, ...
https://arstechnica.com/gadgets/2023/05/cancel-your-winrar-t...
If I recall correctly, xz can be built with both autoconf and cmake, are cmake configs similarly affected?
https://git.tukaani.org/?p=xz.git;a=commit;h=f9cf4c05edd14de...
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.