[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 30 Mar 2024 12:48:50 -0700
From: Andres Freund <andres@...razel.de>
To: oss-security@...ts.openwall.com
Subject: Re: backdoor in upstream xz/liblzma leading to ssh server compromise
Hi,
On 2024-03-29 08:51:26 -0700, Andres Freund wrote:
> The prior section explains that RSA_public_decrypt@....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@...+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
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
