Re: xz backdoor prevention using hosts.deny?

[Jacob Bachmeyer <jcb62281 () gmail com>]

Andres Freund wrote:
> Hi,
>
> On 2024-04-08 23:00:48 -0500, Jacob Bachmeyer wrote:
>   
> > I am not so sure about this.  The original discovery of this backdoor
> > observed a slowdown in refusing a session for a nonexistent account using
> > only SSH publickey auth, *not* SSH certificate auth.  Reports have also
> > suggested that testing began after common botnet scans were observed to be
> > causing sshd to use an inordinate amount of CPU time.  I doubt botnets are
> > presenting certificates either.
> >     
> > I am unsure how sshd would call RSA_public_decrypt in those situations,
> > which suggests that the backdoor blob is more complex than we currently
> > think.
> >     
>
> The slow part of the backdoor is *not* when actually calling
> RSA_public_decrypt(). It's the "initialization" of the backdoor, which happens
> very early during sshd startup, well before reaching main().  Note how, in the
> initial report, even "sshd -h" is slow if called in the right environment.
>   

Yes, but the initial report also gave timings for "ssh 
nonexistent@localhost", see the quote below.

> https://www.openwall.com/lists/oss-security/2024/03/29/4 :
>   
> > In fact, openssh does not need to be started as a server to observe the
> > slowdown:
> >
> > slow:
> > env -i LANG=C /usr/sbin/sshd -h
> >     
Also from <URL:https://www.openwall.com/lists/oss-security/2024/03/29/4>:
> == Observing Impact on openssh server ==
>
> With the backdoored liblzma installed, logins via ssh become a lot slower.
>
> time ssh nonexistant@...alhost
>
> before:
> nonexistant@...alhost: Permission denied (publickey).
>
> before:
> real    0m0.299s
> user    0m0.202s
> sys     0m0.006s
>
> after:
> nonexistant@...alhost: Permission denied (publickey).
>
> real    0m0.807s
> user    0m0.202s
> sys     0m0.006s

This seems to indicate that sshd takes more than twice as long to reject 
a login (using SSH publickey auth, /not/ a certificate) to a 
non-existent account with the backdoor active.

> > In fact, I would expect sshd to reject the connection without ever
> > attempting to verify a signature if the requested account does not exist,
> > yet a significant delay in that rejection led to the discovery of the
> > backdoor.
> >     
>
> See https://www.openwall.com/lists/oss-security/2024/03/30/37 for the path
> leading to certification validation before certificate validity, users, etc
> are checked.
>   

Yes, but that is for logins where the client presents a certificate, 
which I understand that your client did not, only requesting "publickey" 
auth.  How does the backdoor have such a large effect in that scenario?


-- Jacob