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

[Andres Freund <andres () anarazel de>]

Hi,

On 2024-03-29 08:51:26 -0700, Andres Freund wrote:
> The prior section explains that RSA_public_decrypt () got plt was redirected to
> point into the backdoor code. The trace I was analyzing indeed shows that
> during a pubkey login the exploit code is invoked:
>
>             sshd 1736357 [010] 714318.734008:          1  branches:uH:      5555555ded8c ssh_rsa_verify+0x49c 
> (/usr/sbin/sshd) =>     5555555612d0 RSA_public_decrypt@plt+0x0 (/usr/sbin/sshd)
>
> The backdoor then calls back into libcrypto, presumably to perform normal authentication
>
>             sshd 1736357 [010] 714318.734009:          1  branches:uH:      7ffff7c137cd [unknown] 
> (/usr/lib/x86_64-linux-gnu/liblzma.so.5.6.0) =>     7ffff792a2b0 RSA_get0_key+0x0 
> (/usr/lib/x86_64-linux-gnu/libcrypto.so.3)
>
>
> I have not yet analyzed precisely what is being checked for in the injected
> code, to allow unauthorized access. Since this is running in a
> pre-authentication context, it seems likely to allow some form of access or
> other form of remote code execution.

FWIW, RSA_public_decrypt is reachable, regardless of server configuration,
when using certificate based authentication.  Whether the key type is allowed
is only verified after already verifying it
(sshkey_from_blob_internal()->cert_parse()->sshkey_verify()). Whereas for
normal pubkey auth, first the key type is checked, then the key id is checked
against authorized_keys, and only then the key is verified (which also reaches
sshkey_verify()).

Greetings,

Andres Freund