Re: xz backdoor prevention using hosts.deny?

[Andres Freund <andres () anarazel de>]

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.

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


> 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.


Greetings,

Andres Freund