I've analysed the backdoor myself and it's very sophisticated, not poorly made at all. The performance problem is surprising in this context, but I think next time they won't make that mistake.
I guess it seems like the operational parts are a bit poorly done. Valgrind issues, adding a new version with symbols removed, the aforementioned performance issues. Like i would assume the type of person who would do this sort of thing, over a 2 year period no less, would test extensively and be sure all their i's are dotted. Its all kind of surprising given how audacious the attack is.
There are so many variations of Linux/FreeBSD and weird setups and environments that it's almost guaranteed that you'll hit a snag somewhere if you do any major modification like inserting a backdoor.
It's hard enough to get code to work correctly; getting it to be also doing something else is even harder.
The way they went around it, however, was brilliant. Completely reduce the variables to directly target whatever it is you're attacking. Reminds me of stuxnet somewhat.
Note that in this case the backdoor was only inserted in some tarballs and enabled itself only when building deb/rpm packages for x86-64 linux and with gcc and the gnu linker. This should already filter out the most exotic setups and makes it harder to reproduce.
But they almost got away with it. We could have found ourselves 5 years later with this code in all stable distribution versions, IoT devices etc.
Also, we only catch the ones that we ... catch. The ones that do everything perfectly, unless they come out and confess eventually, we don't get to "praise" them for their impeccable work.
Do you have a writeup or any details as to what it does? The logical thing based on this post is that it hooks the SSH key verification mechanism to silently allow some attacker-controlled keys but I wonder if there's more to it?
I was starting one, but the openwall message linked here is far more detailed and gets much further than I did. It's fiendishly difficult to follow the exploit.
sshd starts with root privileges and then proceeds to, in summary:[1]
1. Parse command line arguments
2. Setup logging
3. Load configuration files
4. Load keys/certificates into memory (notably including private keys)
5. Listen on a socket/port for incoming connections
6. Spawn a child process with reduced permissions (on Linux, using seccomp filters [2]) to respond to each incoming connection request
This backdoor executes at order 0 before sshd's main function is invoked, overwriting internal sshd functions with compromised ones. As some ideas of what the backdoor could achieve:
1. Leak server private keys during handshakes with users (including unauthenticated users) allowing the keys to be passively stolen
2. Accept backdoor keys as legitimate credentials
3. Compromise random number generation to disable perfect forward secrecy
4. Execute code on the host (supplied remotely by a malicious user) with the 'root' permissions available to sshd upon launch. On most Linux distributions, systemd-analyze security sshd.service will give a woeful score of 9.6/10 (10 being the worst).[3] There is essentially NO sandboxing used because an assumption is made that you'd want to login as root with sshd (or sudo/su to root) and thus would not want to be restricted in what filesystem paths and system calls your remote shell can then invoke.
The same attacker has also added code to Linux kernel build scripts which causes xz to be executed (xz at this point has a backdoor compiled into it) during the build of the Linux kernel where xz compression is used for the resulting image. Using this approach, the attacker can selectively choose to modify certain (or all) Linux kernel builds to do some very nasty things:
1. Leak Wireguard keys allowing them to be passively intercepted.
2. Compromise random number generation, meaning keys may be generated with minimal entropy (see Debian certificate problem from a few years ago).
3. Write LUKS master keys (keys used by dm-crypt for actually decrypting disks) to disks in retrievable format.
4, Introduce remote root code execution vulnerabilities into basic networking features such as TCP/IP code paths.
