[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 08 Apr 2024 23:00:48 -0500
From: Jacob Bachmeyer <jcb62281@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: xz backdoor prevention using hosts.deny?
Á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
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.
