Re: xz backdoor prevention using hosts.deny?

[Jacob Bachmeyer <jcb62281 () gmail com>]

Ángel wrote:
> On 2024-04-03 at 03:31 +0000, Nick Sal wrote:
>   
> > Hi,
> >
> > Assume we filter SSH access only to a public domain subnet using the
> > files hosts.{deny,allow} as seen below.
> > Would this prevent an attack if a malicious payload was *not* sent
> > from the allowed subnet?
> > Trying to figure out if an attack like this was still possible, for
> > the few days in March the backdoor was active and undetected in
> > rolling distros (e..g. debian testing).
> >
> > /etc/hosts.deny:  sshd: ALL
> > /etc/hosts.allow: sshd: "a_subnet"
> >     
>
> If your sshd uses libwrap, blocking access except from that subnet
> (I would check it is indeed doing what you expect, by trying from an
> external ip) then yes, it would protect from that.
> The libwrap filtering happens before the exchange identification.
>   

Does libwrap filtering happen in the sshd process?  If so, do not be so 
certain.

> > Moreover, allowing only public-key authentication for SSH does not
> > help, isn't this right?
> >     
>
> Right. It doesn't help in this case, since the backdoor happens at the
> preauth phase, when it would be validating the provided public key
> (certificate).

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.  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.  (Lead the client through a fake exchange to hide that the 
account does not exist, sure, but a non-existent account has no 
.ssh/authorized_keys file, so where would sshd get a public key for 
verification?)


-- Jacob