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

[Jeffrey Walton <noloader () gmail com>]

On Sun, Mar 31, 2024 at 5:11 PM Solar Designer <solar () openwall com> wrote:
> On Sat, Mar 30, 2024 at 03:01:31PM -0700, Andres Freund wrote:
> > On 2024-03-30 22:46:17 +0100, Axel Beckert wrote:
> > > On Sat, Mar 30, 2024 at 12:48:50PM -0700, Andres Freund wrote:
> > > > FWIW, RSA_public_decrypt is reachable, regardless of server configuration,
> > > > when using certificate based authentication.
> > >              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > >
> > > Wait, do you really mean SSH keys verified by certificates issued by a
> > > (usually internal, SSH-specific) certificate authority (CA) for a key?
> > >
> > > See e.g.
> > > https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Certificate-based_Authentication
> > > what certificate-based authentication in SSH actually means.
> > >
> > > From my experience certificate-based SSH authentication (i.e. those
> > > algorithms with *-cert-* in their names) is rather rare, while simple
> > > public key authentication (where you just put your according pubkey
> > > into .ssh/authorized_keys) is very common.
> > >
> > > Can you clarify if you really meant that solely certificate based
> > > authentication (with certificates issued by a CA) triggers that code
> > > path or if you actually meant all sorts of public key based
> > > authentication in general?
> >
> > I meant CA based auth - but note that, from what I can tell, you don't need to
> > have it set up on the server side or anything. You might not even be able to
> > disable it. If the client sends a signed key, the signature is loaded and
> > verified before approved algorithms are checked.
> >
> > This seems suboptimal regardless of the backdoor issue, so I opened an
> > enhancement request for openssh: https://bugzilla.mindrot.org/show_bug.cgi?id=3675
> >
> > I might be misreading the code around some of the details, but I did
> > experimentally verify that an rsa signature is verified without CA auth being
> > configured.
>
> keeganryan on GitHub has posted a Python class that may help experiment
> with the above, and with passing commands to the backdoor (but of course
> we don't currently have the private key to sign them with):
>
> https://gist.github.com/keeganryan/a6c22e1045e67c17e88a606dfdf95ae4
>
> class ModifiedRSAClient:
>     """ Connect to a SSH host using a modified RSA public key and signature.
>
>     During public key authentication, an SSH client sends its public key to the SSH host.
>     If this public key is a certificate, the signature of the certificate is verified by
>     OpenSSH. This class allows for modification of the public key and signature in the
>     certificate parsed by OpenSSH.
>     """

> From the crypto perspective, we've told developers to always validate
security parameters, like private keys and public keys, upon loading
them. The concern (for me) was weak keys that could lead to
information disclosure.

This definitely requires a new leaf in the threat model, where the
public key is a payload. What I am less sure of, is it possible to
detect a potential payload using classical security parameter
validation techniques.

Jeff