Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 30 Mar 2024 12:48:50 -0700
From: Andres Freund <>
Subject: Re: backdoor in upstream xz/liblzma leading to ssh server compromise


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/ =>     7ffff792a2b0 RSA_get0_key+0x0 (/usr/lib/x86_64-linux-gnu/
> 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


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.