Hacker News Reader

Comment by rwmj | Hacker News Reader

> However, it's interesting to note that in both 2002 and 2024 we got a backdoor rather than a bugdoor.

As far as we know.

Related, there was a pretty interesting backdoor-by-bug attempt on the Linux kernel (at least, one that we know of) back in 2003: https://lwn.net/Articles/57135/

The Linux "bug" was unsophisticated by modern standards, but you could imagine a modern equivalent that's harder to spot:

Make the "bug" happen across several lines of code, especially if some of those lines are part of existing code (so don't appear in the patch being reviewed). Ensure the compiler doesn't warn about it. Make the set of triggering events very unlikely unless you know the attack. It would be very surprising to me if three letter agencies hadn't done or attempted this.

View on HN

And in 2010, a similar backdoor appeared in UnrealICRD: https://lwn.net/Articles/392201/. Also in proftpd: https://www.aldeid.com/wiki/Exploits/proftpd-1.3.3c-backdoor. Both were done by ac1db1tch3z who the author of OP's post, Ben Hawkes, got a shoutout from for another local privilege escalation vulnerability from over a decade ago :-).

Anyways, in response to the backdoor in unrealircd, Core Security came up with a "hiding backdoors in plain sight" challenge: https://seclists.org/fulldisclosure/2010/Jul/66

"Bugdoors" are not new, and I'm sure some have been patched without anybody realizing they were introduced maliciously.

And there was the socat backdoor

Oh man! I’d forgotten all about the UnrealIRCd backdoor! I was running an IRC network at the time. What a blast from the past.

The problem with these is that bugdoors require you to target way more valuable stuff compared to backdoors. With a backdoor you can target practically any library or binary that is being run with root privileges, while with a bugdoor you can only really target code that is directly interacting with a network connection.

Direct network facing code is much more likely to have stringent testing and code review for all changes, so as of now it seems a bit easier to target codebases with very little support and maintenance compared to an attack that would target higher value code like OpenSSH or zlib.

To think that there's a safe somewhere in a TLA basement with a "how to get root anywhere" tutorial.

I imagine there's a cross-TLA committee that analyses all the available zerodays, and meets quarterly to prioritise what order and which agencies can burn those zerodays when needed. And probably KPIs for each agency to add new zerodays which move their agency higher up the list to potentially burn the really good ones.

Reply on news.ycombinator.com