Path: ...!npeer.as286.net!npeer-ng0.as286.net!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Nuno Silva <nunojsilva@invalid.invalid>
Newsgroups: comp.os.linux.misc
Subject: Re: Malware find in the news: xz related.
Date: Sun, 31 Mar 2024 16:45:08 +0100
Organization: A noiseless patient Spider
Lines: 44
Message-ID: <uuc04d$1s3mb$1@dont-email.me>
References: <uu7r9s$kh5b$2@dont-email.me> <uua83j$19ff9$1@dont-email.me>
	<6608ab05@news.ausics.net> <6608acc9@news.ausics.net>
	<27bd4b53-920c-f119-6d15-7e844d4a39ea@example.net>
	<uubq8s$1qpft$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Sun, 31 Mar 2024 15:39:57 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="1bdb957d15eb057ff0f1f94b28f1d63f";
	logging-data="1969867"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+dbwJbGsLAmp1pgphlsybM"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
Cancel-Lock: sha1:YCfQnTj5GEldRIIr/A4XP0YeoDA=
Bytes: 2693

On 2024-03-31, Lew Pitcher wrote:

> On Sun, 31 Mar 2024 11:29:08 +0200, D wrote:
>
>> On Sun, 31 Mar 2024, Computer Nerd Kev wrote:
>> 
>>> Computer Nerd Kev <not@telling.you.invalid> wrote:
>>>> MarioCCCP <NoliMihiFrangereMentulam@libero.it> wrote:
>>>>>
>>>>> any hints to patch the vulnerability, or will it be
>>>>> addressed soon and be released as security updates ?
>>>>
>>>> The code was targeting Debian, and only reached the Testing version
>>>> of Debian
>>>
>>> And RHEL, and of course all the distros based on those (or at least
>>> those using Systemd).
>>>
>>>
>> 
>> How is this exploited? Does it require login/pw?
>
> 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.
>
> HTH

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

-- 
Nuno Silva