[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 09 Apr 2024 22:13:24 -0500
From: Jacob Bachmeyer <jcb62281@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: xz backdoor prevention using hosts.deny?
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@...alhost", 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
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.
