Hacker News Reader

> 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

I'm honestly surprised that this autoconf vector hasn't happened more often... or more often that we know of.

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

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

It's weird and disturbing that this isn't the default perspective.

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.

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.

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.

Surely this is happening right now.

A lot of eyes are on the code. From all sides. Folks trying to find old unpatched backdoors to exploit or patch.

it's not weird at all?

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.

* I swear that HN has the least-thought-through hot takes of any media in the world.*

The irony is too good.

Yeah if you tried to revert stuff that was done weeks ago on a relatively small team you know how much painstaking work it can be.

You can't just go and rip out old code, it'll break everything else, you have to review each commit and decide what to do with each.

"immediately" could mean have humans swarm on the task and make a choice, as opposed to

    for commit in author_commits
        git revert $commit

Imagine someone tried to revert all the commits you ever did. Doesn't sound easy.

Too much fallout.

Rolling back two years worth of commits made by a major contributor is going to be hell. I'm looking forward to see how they'll do this.

Not really. xz worked fine 2 years ago. Roll back to 5.3.1 and apply a fix for the 1 security hole that was fixed since that old version. (ZDI-CAN-16587)

Slight oversimplification, see https://bugs.debian.org/1068024 discussion.

This seems true with so many of these core libraries. Change for the sake of change introduces attack vectors. If it ain't broke, don't fix it!

Yeah but people will cry "dead project" if there hasn't been a release for a week.

Hoe will you do that practically though? That’s probably thousands of commits upon which tens or hundred thousand commits from others were built. You can’t just rollback everything two years and expect it not to break or bring back older vulnerabilities that were patched in those commits.

Likely part of what the attacker(s) are counting on. Anyone want to place odds this isn't the only thing that's going to be found?

I’d bet you at even odds that nothing else malicious by this person is found in 1 month, and at 1:2.5 odds that nothing is found in a year.

Only if you consider "this person" to be equal to "this identity".

I don’t thinks that’s necessary: there are enough eyes on this person’s work now.

No one will do it seriously

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

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

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.

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

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.

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.

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.

Or hiring them to do it for years without telling them why until they need a favor.

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

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.

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.

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

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.

annoying ... and convenient for some!

There was a DARPA program on this topic called Social Cyber. [1]

1. https://www.darpa.mil/program/hybrid-ai-to-protect-integrity...

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.

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?

The computer abuse and fraud act? Seems like a pretty easy question to answer.

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

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

I think this thread is talking at cross-purposes.

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

Talking at cross-purposes?

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.

I'm not looking for a loophole or a legal hypothetical, I'm wondering if our laws are keeping up, which they very often do not with tech.

This is not unauthorized access, but is also clearly wrong. I'm wondering if its illegal, or if its unauthorized access . . .

And of course an attacker like this has a high likelihood of being a state actor, comfortably secure in their native jurisdiction.

> but it seems like anyone can publish an exploit on the internet without being a crime

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]

Some types of criminal cases are only pursued on a victim's complaint.

Not this kind!

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

By this logic you could say that leaving a poisoned can of food in a public pantry is not a crime because poison is legal for academic purposes, and whoever ate it took it willingly.

Also, I think getting malicious code into a repo counts as a compromise in and of itself.

Or shooting someone isn't a crime, since you only pulled the trigger. After all it was the bullet that killed them

Similar laws we use to prosecute someone who intentionally brought a poisened cake to the potluck.

Are you suggesting intent is impossible to determine?

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

Yes, there is evidence of sabotage on the CMake configs too.

https://git.tukaani.org/?p=xz.git;a=commit;h=f9cf4c05edd14de...

How about wheels in the python ecosystem

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.