Re: backdoor in upstream xz/liblzma leading to ssh server compromise

Related Vulnerabilities: CVE-2024-3094  
                Let me reshare one more piece of information: this backdoor is an RCE,
not an authentication bypass.

https://bsky.app/profile/filippo.abyssdomain.expert/post/3kowjkx2njy2b

Copy-pasting all the text written by Filippo Valsorda from there below.

=====
Filippo Valsorda
@filippo.abyssdomain.expert
I'm watching some folks reverse engineer the xz backdoor, sharing some
*preliminary* analysis with permission. The hooked RSA_public_decrypt
verifies a signature on the server's host key by a fixed Ed448 key,
and then passes a payload to system(). It's RCE, not auth bypass, and
gated/unreplayable.

This might be the best executed supply chain attack we've seen
described in the open, and it's a nightmare scenario: malicious,
competent, authorized upstream in a widely used library. Looks like
this got caught by chance. Wonder how long it would have taken
otherwise.

The payload is extracted from the N value (the public key) passed to
RSA_public_decrypt, checked against a simple fingerprint, and
decrypted with a fixed ChaCha20 key before the Ed448 signature
verification.

RSA_public_decrypt is a (weirdly named) signature verification
function. https://www.openssl.org/docs/manmaster/man3/RSA_public_decrypt.html
(Why "decrypt"? RSA sig verification is the same op of RSA encryption.
🤷‍♂️)

The RSA_public_decrypt public key can be attacker-controlled pre-auth
by using OpenSSH certificates. OpenSSH certs are weird in that they
include the signer's public key. OpenSSH checks the signature on
parsing. 
https://github.com/openssh/openssh-portable/blob/281ea25a44bff53eefb4af7bab7aa670b1f8b6b2/PROTOCOL.certkeys#L207-L219

Here's a script by Keegan Ryan for sending a custom public key in a
certificate, which on a backdoored system will reach the hooked
function. https://gist.github.com/keeganryan/a6c22e1045e67c17e88a606dfdf95ae4

Apparently the backdoor reverts back to regular operation if the
payload is malformed or the signature from the attacker's key doesn't
verify. Unfortunately, this means that unless a bug is found, we can't
write a reliable/reusable over-the-network scanner.

On Sat, Mar 30, 2024 at 12:09 AM Andres Freund <andres () anarazel de> wrote:

-- 
Alexander E. Patrakov