Re: Malware find in the news: xz related.

Nuno Silva <nunojsilva@invalid.invalid> writes:

On 2024-03-31, Lew Pitcher wrote:

An "infected" system just needs an SSH server exposed to the internet
to be exploited. The "bad actor" uses a pre-built key to initiate
contact and contact doesn't go any further than key validation.
>
However, the key validation of a bad-actor key causes SSHd to extract
a payload from the key, and pass that payload to a system(3) call.
>
So, while the "bad actor" initiator never officially "logs on" to
the system (no userid, etc), they are afforded sshd privilege-level
access to the system to run commands.

>
If I understand correctly (please correct me if I'm wrong!), it's a
certificate, not a key. While this may sound like nitpicking, in this
case it seems to matter a lot, because for *certificates*, the hijacked
function is invoked even if certificate authentication is not enabled.
>
https://bugzilla.mindrot.org/show_bug.cgi?id=3675

You’re both right: the payload is conveyed the public modulus of a
(purported) RSA key, but the hooked function (RSA_public_decrypt)
performs signature verification (not key validation), and sshd’s rather
eager approach to user certificate verification seems to be the most
promising target for the attacker.

More info:
1) https://openwall.com/lists/oss-security/2024/03/29/4
2) https://openwall.com/lists/oss-security/2024/03/30/36
3) https://openwall.com/lists/oss-security/2024/03/30/37

The bit in #2 about verifying a signature under a server’s host key
doesn’t sound quite right: the attack (in the form presented in xz) only
attacks sshd, which generates signatures using host keys, rather than
verifying them.

Incredibly good luck that it was spotted before it was too widely
deployed. Or bad luck if you were the originator l-)

--
https://www.greenend.org.uk/rjk/