I think ideas about prevention should be more concerned with the social engineering aspect of this attack. The code itself is certainly cleverly hidden, but any bad actor who gains the kind of access as Jia did could likely pull off something similar without duplicating their specific method or technique.

Somebody wrote a PoC for it: https://github.com/amlweems/xzbot#backdoor-demo

Basically, if you have a patched SSH client with the right ED448 key you can have the gigged sshd on the other side run whatever commands you want. The demo just does id > /tmp/.xz but it could be whatever command you want.

I am not a security expert, but the scenario they describe sounds exactly like authentication bypass to a layman like me.

According to https://www.youtube.com/watch?v=jqjtNDtbDNI the software installs a malicious library that overwrite the signature verification function of ssh.

I was wondering if the bypass function was designed to be slightly less resource intensive, it probably won't be discovered and will be shipped to production.

Also I have mixed feeling about dynamic linking, on the one hand, it allows projects like harden malloc to easily integrate into the system, on the other hand, it also enables the attacker to hijack the library in a similar fashion.

EDIT: This is a remote code execution exploit, not authentication bypass. The payload is sent as an authentication message and will be executed by the compromised authentication function.

This means:

• the payload will be executed as root, since sshd run as root.
• the payload will leave no trace in login log.

So this is much worse than ssh authentication bypass.

Under the right circumstances this interference could potentially enable a malicious actor to break sshd authentication and gain unauthorized access to the entire system remotely. —Wikipedia, sourced to RedHat

Of course, the authentication bypass allows remote code execution.