I just saw this while looking through a news feed.

https://www.helpnetsecurity.com/2024/03/29/cve-2024-3094-linux-backdoor/

I have not read the entire article yet, but it has been said to have been
found accidentally.

pH in Aptos

pH wrote:
> I just saw this while looking through a news feed.
>
> https://www.helpnetsecurity.com/2024/03/29/cve-2024-3094-linux-backdoor/
>
> I have not read the entire article yet, but it has been said to have been
> found accidentally.
>
> pH in Aptos
>

"stop using Fedora 41" sounds pretty serious....

In comp.os.linux.misc, pH <wNOSPAMp@gmail.org> wrote:
> I just saw this while looking through a news feed.
>
> https://www.helpnetsecurity.com/2024/03/29/cve-2024-3094-linux-backdoor/
>
> I have not read the entire article yet, but it has been said
> to have been
> found accidentally.

The initial report is quite readable:

https://www.openwall.com/lists/oss-security/2024/03/29/4

Found because someone was trying to benchmark something else and ssh was
using noticable cpu. An exploit hidden by a multi-year contributor who
got promoted to maintainer. The exploit is hidden in a "bad" xz
compessed "test" file, a simple use of `tr` repairing the file. Today's
exploit specifically targets sshd on Debian, but there's no reason to
think that this was a final target instead of a first target.

Elijah
------
Easter weekend security scamble

On 30/03/24 02:53, pH wrote:
> I just saw this while looking through a news feed.
>
> https://www.helpnetsecurity.com/2024/03/29/cve-2024-3094-linux-backdoor/
>
> I have not read the entire article yet, but it has been said to have been
> found accidentally.
>
> pH in Aptos

any hints to patch the vulnerability, or will it be
addressed soon and be released as security updates ?

--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP

Eli the Bearded <*@eli.users.panix.com> wrote:
> The initial report is quite readable:
>
> https://www.openwall.com/lists/oss-security/2024/03/29/4
>
> Found because someone was trying to benchmark something else and ssh was
> using noticable cpu. An exploit hidden by a multi-year contributor who
> got promoted to maintainer. The exploit is hidden in a "bad" xz
> compessed "test" file, a simple use of `tr` repairing the file. Today's
> exploit specifically targets sshd on Debian, but there's no reason to
> think that this was a final target instead of a first target.

True, though that post does mention that the exploit actually
relies on a Debian patch to OpenSSH which causes sshd to be linked
to the XZ compression library via a dependency on libsystemd:
"openssh does not directly use liblzma. However debian and several
other distributions patch openssh to support systemd notification,
and libsystemd does depend on lzma."

This post provides a patch for starting a child process from sshd
to talk to Systemd then exit, instead of linking the SSH server
to libsystemd directly. So it's not the only way that Systemd
integration can be done by distros (if they feel compelled to do it
at all).
https://www.openwall.com/lists/oss-security/2024/03/29/23

They also point out how many libraries are unnecessarily linked to
sshd by existing distro patches. On RHEL 9.x they say "ldd sshd"
lists 28 dynamically-linked libraries, but for their "Rocky Linux
SIG/Security override package" they've got it down to 13.

On Debian 11 (bookworm) with OpenSSH_8.4p1 I see by running ldd on
/sbin/sshd that it's linked to 31 libraries. But on Tiny Core Linux
14, which doesn't use Systemd, OpenSSH_9.5p1 links to only 8
libraries, and doesn't link to liblzma.

On OpenWRT 23 I use Dropbear v2022.82 and ldd shows that it links
to just 3 libraries!

So the attack surface of the SSH server process varies wildly
between distros. Indeed my first thought when I read about this was
"Huh, I didn't know that OpenSSH supported XZ compression". Turns
out it doesn't, but Systemd does.

--
__ __
#_ < |\| |< _#

MarioCCCP <NoliMihiFrangereMentulam@libero.it> wrote:
> On 30/03/24 02:53, pH wrote:
>> I just saw this while looking through a news feed.
>>
>> https://www.helpnetsecurity.com/2024/03/29/cve-2024-3094-linux-backdoor/
>>
>> I have not read the entire article yet, but it has been said to have been
>> found accidentally.
>>
>> pH in Aptos
>
> 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, so unless you're running that it's unlikely to matter.
But the advice is to downgrade (which may be effected now as an
upgrade within package managers) from the affected liblzma versions
5.6.0 and 5.6.1 to a previous version if you're not using an older
verison already anyway.

Here's a summary of the problem and what to do:
https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27

Linked from this official page on the XZ Utils project author's
website:
https://tukaani.org/xz-backdoor/

--
__ __
#_ < |\| |< _#

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

--
__ __
#_ < |\| |< _#

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?

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

presumably wanted to get into Suse enterprise as well, but that is less
clear. It got to Tumbleweed, however that is too far removed from
enterprise. They tried to get it into next Ubuntu but failed.

pH <wNOSPAMp@gmail.org> wrote:
> I just saw this while looking through a news feed.
>
> https://www.helpnetsecurity.com/2024/03/29/cve-2024-3094-linux-backdoor/
>
> I have not read the entire article yet, but it has been said to
> have been found accidentally.
>
> pH in Aptos

Thanks, here is another interesting link that describes how
the issue occurred and indicates why *BSD and Distros like
Slackware would not be vulnerable.

https://lcamtuf.substack.com/p/technologist-vs-spy-the-xz-backdoor

--
[t]csh(1) - "An elegant shell, for a more... civilized age."
- Paraphrasing Star Wars

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
--
Lew Pitcher
"In Skills We Trust"

On 2024-03-31 01:22, 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).
>

openSUSE Tumbleweed and openSUSE MicroOS are affected.

Not Leap nor SLES.

--
Cheers, Carlos.

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

On Sun, 31 Mar 2024 16:45:08 +0100, Nuno Silva wrote:

> 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

I believe that you are correct. My memory of the details was incorrect.

--
Lew Pitcher
"In Skills We Trust"

On 3/31/24 08:38, John McCue wrote:
> Thanks, here is another interesting link that describes how the issue
> occurred and indicates why *BSD and Distros like Slackware would not
> be vulnerable.

My understanding is that effectively the differentiating factor of if a
distro is impacted or not is if it uses systemd or not.

Purportedly sshd itself doesn't use xz. But sshd built on / for systemd
distros end up having xz added as a library / dependency because of
systemd compatibility because systemd does use xz for things.

As such, my supposition is that, things like *BSD, Slackware, and Gentoo
(OpenRC old default) aren't affected because they don't have -> use systemd.

--
Grant. . . .

On Sun, 31 Mar 2024 10:23:41 -0400, Carlos E.R. <robin_listas@es.invalid> wrote:

> On 2024-03-31 01:22, 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).
>>
>
> openSUSE Tumbleweed and openSUSE MicroOS are affected.
>
> Not Leap nor SLES.

Mageia is not affected either. The 5.6.0 and 5.6.1 versions were not imported
into Mageia.

Regards, Dave Hodgins

Nuno Silva <nunojsilva@invalid.invalid> wrote:
> On 2024-03-31, Lew Pitcher wrote:
>
>> On Sun, 31 Mar 2024 11:29:08 +0200, D wrote:
>>> 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
>

Given that it is a "backdoor", nitpicking whether it is a 'key' or a
'certificate' for activation is a bit of bikeshedding. It hardly
matters that the bad actor used a "key" or a "certificate" to open
their backdoor when they get the ability to run arbitrary commands on
your system as the root user because of that same backdoor.

On Sun, 31 Mar 2024 12:05:58 -0400, Grant Taylor <gtaylor@tnetconsulting.net> wrote:

> On 3/31/24 08:38, John McCue wrote:
>> Thanks, here is another interesting link that describes how the issue
>> occurred and indicates why *BSD and Distros like Slackware would not
>> be vulnerable.
>
> My understanding is that effectively the differentiating factor of if a
> distro is impacted or not is if it uses systemd or not.

sshd supports compression. xz is an option for how things are compressed.

Regards, Dave Hodgins

Grant Taylor <gtaylor@tnetconsulting.net> wrote:
> On 3/31/24 08:38, John McCue wrote:
>> Thanks, here is another interesting link that describes how the issue
>> occurred and indicates why *BSD and Distros like Slackware would not
>> be vulnerable.
>
> My understanding is that effectively the differentiating factor of if
> a distro is impacted or not is if it uses systemd or not.

Yes, this seems to have been part of the "connection".

> Purportedly sshd itself doesn't use xz.

It does not. Directly that is.

> But sshd built on / for systemd distros end up having xz added as a
> library / dependency because of systemd compatibility because systemd
> does use xz for things.

Some distros, in their zeal to "systemd all the things" patch OpenSSH
to link it to a systemd library for logging purposes. That addition of
a systemd library for logging is what ultimately linked the xz/lzma
library into OpenSSH because somewhere in that systemd libraries
dependency chain was libxz/lzma.

> As such, my supposition is that, things like *BSD, Slackware, and
> Gentoo (OpenRC old default) aren't affected because they don't have
> -> use systemd.

They are not, because their OpenSSH is not linked to libxz/lzma in any
way.

But.... this is nearly a "Reflections on Trusting Trust" [1] level
opsec. attempt, and so just because BSD/Slackware/Gentoo happen to be
immune this time, does not mean they would be immune to another opsec.
attempt against an OpenSSH direct dependency which might gain a
similarly well hidden backdoor.

On my Slack 15.0 system, sshd directly links to the following
libraries:

$ ldd /usr/sbin/sshd
linux-vdso.so.1 (0x00007ffee1ab9000)
libnsl.so.2 => /lib64/libnsl.so.2 (0x00007fdb09586000)
libpam.so.0 => /lib64/libpam.so.0 (0x00007fdb09575000)
libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007fdb09290000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fdb0928b000)
libutil.so.1 => /lib64/libutil.so.1 (0x00007fdb09286000)
libz.so.1 => /lib64/libz.so.1 (0x00007fdb0926c000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007fdb09230000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fdb09216000)
libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007fdb091c4000)
libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007fdb090ed000)
libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007fdb090bf000)
libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007fdb090b9000)
libc.so.6 => /lib64/libc.so.6 (0x00007fdb08ed8000)
libtirpc.so.3 => /lib64/libtirpc.so.3 (0x00007fdb08ea8000)
/lib64/ld-linux-x86-64.so.2 (0x00007fdb096cf000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fdb08e87000)
libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00007fdb08e78000)
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007fdb08e71000)

A similar backdoor in any one of these would open up sshd for remote
access, even though I have no systemd anywhere on my system.

[1] https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf

On Sun, 31 Mar 2024 12:26:20 -0400, Rich <rich@example.invalid> wrote:

> Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>> On 3/31/24 08:38, John McCue wrote:
>>> Thanks, here is another interesting link that describes how the issue
>>> occurred and indicates why *BSD and Distros like Slackware would not
>>> be vulnerable.
>>
>> My understanding is that effectively the differentiating factor of if
>> a distro is impacted or not is if it uses systemd or not.
>
> Yes, this seems to have been part of the "connection".
>
>> Purportedly sshd itself doesn't use xz.
>
> It does not. Directly that is.
>
>> But sshd built on / for systemd distros end up having xz added as a
>> library / dependency because of systemd compatibility because systemd
>> does use xz for things.
>
> Some distros, in their zeal to "systemd all the things" patch OpenSSH
> to link it to a systemd library for logging purposes. That addition of
> a systemd library for logging is what ultimately linked the xz/lzma
> library into OpenSSH because somewhere in that systemd libraries
> dependency chain was libxz/lzma.
>
>> As such, my supposition is that, things like *BSD, Slackware, and
>> Gentoo (OpenRC old default) aren't affected because they don't have
>> -> use systemd.
>
> They are not, because their OpenSSH is not linked to libxz/lzma in any
> way.

The link to systemd is an after the fact detail. Likely systemd was intended
as another target, but the attack was caught before it got that far.

The key in deciding whether or not a distribution is impacted, is whether
or not it includes version 5.6.0 or 5.6.1 of xz.

The remote code execution is in those versions of the xz package.

Once the RCE is available, ssh is vulnerable as sshd supports compression
and xz is one option for compression. It doesn't matter whether xz is linked
in to sshd or called at run time to decompress the data.

https://gynvael.coldwind.pl/?lang=en&id=782
https://tukaani.org/xz-backdoor/

The RCE just happened to be found while running detailed timing tests that
included sshd with xz compression support. It impacts anything that supports
using xz as a compression utility, or any xz decompression of untrusted input
by an end user or other system service.

Regards, Dave Hodgins

David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
> On Sun, 31 Mar 2024 12:05:58 -0400, Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>
>> On 3/31/24 08:38, John McCue wrote:
>>> Thanks, here is another interesting link that describes how the issue
>>> occurred and indicates why *BSD and Distros like Slackware would not
>>> be vulnerable.
>>
>> My understanding is that effectively the differentiating factor of if a
>> distro is impacted or not is if it uses systemd or not.
>
> sshd supports compression. xz is an option for how things are compressed.

ssh supports zlib compression. It (ssh) does not offer lzma/xz as a
compression option.

xz got pulled into ssh on systemd systems because systemd supports
using xz/lzma for journald compression, and it is therefore a
dependency of libsystemd. Some distros patch sshd to link to
libsystemd so that their sshd can "notify" systemd that it is up via a
call to a libsystemd function.

On 2024-03-31 18:26, Rich wrote:
> Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>> On 3/31/24 08:38, John McCue wrote:
>>> Thanks, here is another interesting link that describes how the issue
>>> occurred and indicates why *BSD and Distros like Slackware would not
>>> be vulnerable.
>>
>> My understanding is that effectively the differentiating factor of if
>> a distro is impacted or not is if it uses systemd or not.
>
> Yes, this seems to have been part of the "connection".
>
>> Purportedly sshd itself doesn't use xz.
>
> It does not. Directly that is.
>
>> But sshd built on / for systemd distros end up having xz added as a
>> library / dependency because of systemd compatibility because systemd
>> does use xz for things.
>
> Some distros, in their zeal to "systemd all the things" patch OpenSSH
> to link it to a systemd library for logging purposes. That addition of
> a systemd library for logging is what ultimately linked the xz/lzma
> library into OpenSSH because somewhere in that systemd libraries
> dependency chain was libxz/lzma.
>
>> As such, my supposition is that, things like *BSD, Slackware, and
>> Gentoo (OpenRC old default) aren't affected because they don't have
>> -> use systemd.
>
> They are not, because their OpenSSH is not linked to libxz/lzma in any
> way.
>
> But.... this is nearly a "Reflections on Trusting Trust" [1] level
> opsec. attempt, and so just because BSD/Slackware/Gentoo happen to be
> immune this time, does not mean they would be immune to another opsec.
> attempt against an OpenSSH direct dependency which might gain a
> similarly well hidden backdoor.

A well funded bad actor will likely find a target to do their thing.
They did not attack systemd directly, but a small auxiliary library from
another project, one that had little attention from developers. Once
this hole is plugged, they will seek another one.

That was a two year investment to plant a mole. There might be others.

--
Cheers, Carlos.

On Sun, 31 Mar 2024 13:38:32 -0400, Rich <rich@example.invalid> wrote:

> David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
>> On Sun, 31 Mar 2024 12:05:58 -0400, Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>>
>>> On 3/31/24 08:38, John McCue wrote:
>>>> Thanks, here is another interesting link that describes how the issue
>>>> occurred and indicates why *BSD and Distros like Slackware would not
>>>> be vulnerable.
>>>
>>> My understanding is that effectively the differentiating factor of if a
>>> distro is impacted or not is if it uses systemd or not.
>>
>> sshd supports compression. xz is an option for how things are compressed.
>
> ssh supports zlib compression. It (ssh) does not offer lzma/xz as a
> compression option.
>
> xz got pulled into ssh on systemd systems because systemd supports
> using xz/lzma for journald compression, and it is therefore a
> dependency of libsystemd. Some distros patch sshd to link to
> libsystemd so that their sshd can "notify" systemd that it is up via a
> call to a libsystemd function.

Perhaps ssh is only impacted on systemd systems, but anything processing
untrusted xz compressed files, such as clamav is still vulnerable, so the
statement that only systems using systemd are vulnerable is not correct.

Any system using xz 5.6.0 or 5.6.1 is vulnerable.

Regards, Dave Hodgins

On Sun, 31 Mar 2024 14:51:06 -0400, David W. Hodgins wrote:

> On Sun, 31 Mar 2024 13:38:32 -0400, Rich <rich@example.invalid> wrote:
>
>> David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
>>> On Sun, 31 Mar 2024 12:05:58 -0400, Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>>>
>>>> On 3/31/24 08:38, John McCue wrote:
>>>>> Thanks, here is another interesting link that describes how the issue
>>>>> occurred and indicates why *BSD and Distros like Slackware would not
>>>>> be vulnerable.
>>>>
>>>> My understanding is that effectively the differentiating factor of if a
>>>> distro is impacted or not is if it uses systemd or not.
>>>
>>> sshd supports compression. xz is an option for how things are compressed.
>>
>> ssh supports zlib compression. It (ssh) does not offer lzma/xz as a
>> compression option.
>>
>> xz got pulled into ssh on systemd systems because systemd supports
>> using xz/lzma for journald compression, and it is therefore a
>> dependency of libsystemd. Some distros patch sshd to link to
>> libsystemd so that their sshd can "notify" systemd that it is up via a
>> call to a libsystemd function.
>
> Perhaps ssh is only impacted on systemd systems, but anything processing
> untrusted xz compressed files, such as clamav is still vulnerable, so the
> statement that only systems using systemd are vulnerable is not correct.
>
> Any system using xz 5.6.0 or 5.6.1 is vulnerable.

In theory, yes. And, "its better to be safe than sorry"

But, from my (admittedly very limited) understanding of the backdoor (as
currently exposed), the bad code in xz specifically targets sshd, and (from
current indications) no other application.

Still, if I had one of the suspicious xz/liblzma packages installed, I'd
not hesitate to "nuke it from orbit" and replace it with a known-good version.

Again, "its better to be safe than sorry".

--
Lew Pitcher
"In Skills We Trust"

On 3/31/24 11:13, David W. Hodgins wrote:
> sshd supports compression. xz is an option for how things are compressed.

I've read multiple reports that OpenSSH upstream does not support xz
compression.

Yes, OpenSSH does support multiple forms of compression, but xz is not
one of the form supported by upstream OpenSSH proper.

xz support was brought in by things downstream.

--
Grant. . . .