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
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.
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
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.
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 ?
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
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).
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).
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
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 <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 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
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
Thanks, here is another interesting link that describes how the issue occurred and indicates why *BSD and Distros like Slackware would not
be vulnerable.
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.
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
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.
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 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.
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.
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.
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 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:ssh supports zlib compression. It (ssh) does not offer lzma/xz as a
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. >>
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.
sshd supports compression. xz is an option for how things are compressed.
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.
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.
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.
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.
The big trouble with that: You need to think that your entire system
is compromised, including the files you had there, passwords you typed, private keys used.
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.
On 31.03.2024 um 19:15 Uhr Lew Pitcher wrote:
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.
I'm not a fan of nuke it from orbit as a knee jerk reaction that some
people have.
On 3/31/24 14:27, Marco Moock wrote:
The big trouble with that: You need to think that your entire system
is compromised, including the files you had there, passwords you typed,
private keys used.
There are two primary forms of compromise here; disclosure and
alteration. The first is somewhat difficult to prove didn't happen.
The second one can be quite easy to do with good backup systems.
Good backup systems that have sufficient history can tell when files
change by comparing content (not just date / time / size / checksum).
As such you can tell what files have been modified and when. With this knowledge, you can relatively easily go back to trusted versions across
the entire system (at least what's covered by the backup).
There are almost always ways to return a system to a safe state to use.
It's just that they often take more time and effort than nuking the
entire system from orbit.
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
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.
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
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.
On Sun, 31 Mar 2024, Carlos E.R. wrote:
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.
I'm one hundred percent sure state level actors are already doing this
in numerous small auxiliary libraries as well as python pip, rust, go
and others.
Seems like supply chain attacks will be the new gold when it comes to malicious attacks. =(
Is the open source community equipped to handle this?
On Sun, 31 Mar 2024, Carlos E.R. wrote:
On 2024-03-31 01:22, Computer Nerd Kev wrote:Are you sure? I check with ldd on my leap 15.5 and it links to the compression library. But maybe another version perhaps.
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.
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
But my understanding of the xz RCE is that it is specifically written
for xz to be indirectly pulled into OpenSSH / sshd via systemd and
that it is expecting very specific behavior / assumptions. I
seriously doubt that those assumptions will be valid in other things.
Could the root hole in xz be abused as a gadget to target other things besides sshd-modified-for-systemd? Probably. Or at least it
conceptually could have if it hadn't been discovered.
On 2024-03-31 22:46, D wrote:
Seems like supply chain attacks will be the new gold when it comes to
malicious attacks. =(
Is the open source community equipped to handle this?
I see a business opportunity for commercial distros.
On 3/31/24 11:26, Rich wrote:
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.
N.B. there is a big difference in saying that *BSD / Slackware / Gentoo (OpenRC) aren't effected by the topic at hand because they aren't using systemd and
saying that they are obviously more secure because they aren't
vulnerable to the topic at hand.
The former statement is probably relatively safe. The latter statement
is almost certainly unsafe.
N.B. there is a big difference in saying that *BSD / Slackware /
Gentoo (OpenRC) aren't effected by the topic at hand because they
aren't using systemd and saying that they are obviously more secure
because they aren't vulnerable to the topic at hand.
On 31.03.2024 um 19:15 Uhr Lew Pitcher wrote:
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.
I'm not a fan of nuke it from orbit as a knee jerk reaction that some
people have.
On 3/31/24 14:27, Marco Moock wrote:
The big trouble with that: You need to think that your entire
system is compromised, including the files you had there, passwords
you typed, private keys used.
There are two primary forms of compromise here; disclosure and
alteration. The first is somewhat difficult to prove didn't happen
The second one can be quite easy to do with good backup systems.
On 2024-03-31 22:39, D wrote:
On Sun, 31 Mar 2024, Carlos E.R. wrote:
On 2024-03-31 01:22, Computer Nerd Kev wrote:Are you sure? I check with ldd on my leap 15.5 and it links to the
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.
compression library. But maybe another version perhaps.
I am certain, from the information posted by openSUSE.
Leap uses old versions of almost everything.
Incredibly good luck that it was spotted before it was too widely
deployed. Or bad luck if you were the originator l-)
On 2024-03-31 23:37, Richard Kettlewell wrote:
Incredibly good luck that it was spotted before it was too widely
deployed. Or bad luck if you were the originator l-)
I saw a post (es.comp.os.linux.redes) of someone in which the sshd
had weird peaks of high cpu (40%)
Carlos E.R. <robin_listas@es.invalid> wrote:
On 2024-03-31 22:46, D wrote:
Seems like supply chain attacks will be the new gold when it comes to
malicious attacks. =(
Is the open source community equipped to handle this?
I see a business opportunity for commercial distros.
Except that brings up the threat that was suggested in the article
that John McCue linked to earlier in the thread. Businesses can
simply be told by governments or anyone sufficiently powerful to
ignore a backdoor that's been put in, likely reporting any such
discovery to them instead.
Except that brings up the threat that was suggested in the article
that John McCue linked to earlier in the thread. Businesses can
simply be told by governments or anyone sufficiently powerful to
ignore a backdoor that's been put in, likely reporting any such
discovery to them instead.
Carlos E.R. <robin_listas@es.invalid> wrote:
On 2024-03-31 22:46, D wrote:
Seems like supply chain attacks will be the new gold when it comes to
malicious attacks. =(
Is the open source community equipped to handle this?
I see a business opportunity for commercial distros.
Except that brings up the threat that was suggested in the article
that John McCue linked to earlier in the thread. Businesses can
simply be told by governments or anyone sufficiently powerful to
ignore a backdoor that's been put in, likely reporting any such
discovery to them instead.
I can understand that, but this is the only really secure variant.
Although, it is a serious threat because it somebody recorded
passwords you typed or got secret keys, all of those machines can be compromised now.
Although, it can't help against disclosure and that means passwords
and keys MAY be known to others now.
Carlos E.R. <robin_listas@es.invalid> wrote:
On 2024-03-31 23:37, Richard Kettlewell wrote:
Incredibly good luck that it was spotted before it was too widely
deployed. Or bad luck if you were the originator l-)
I saw a post (es.comp.os.linux.redes) of someone in which the sshd
had weird peaks of high cpu (40%)
The individual who discovered the backdoor was doing some kind of
performance testing of PostgreSQL. Because of that they were
monitoring their system's processe's usage and noticed unusual CPU
usage from sshd. When they started digging into why sshd was spiking
CPU usage (because it was messing with their PostgreSQL performance monitoring) they discovered the sshd backdoor.
I'm one hundred percent sure state level actors
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
On 2024-04-01 16:03, Rich wrote:
Carlos E.R. <robin_listas@es.invalid> wrote:
On 2024-03-31 23:37, Richard Kettlewell wrote:
Incredibly good luck that it was spotted before it was
too widely
deployed. Or bad luck if you were the originator l-)
I saw a post (es.comp.os.linux.redes) of someone in which
the sshd
had weird peaks of high cpu (40%)
The individual who discovered the backdoor was doing some
kind of
performance testing of PostgreSQL. Because of that they were
monitoring their system's processe's usage and noticed
unusual CPU
usage from sshd. When they started digging into why sshd
was spiking
CPU usage (because it was messing with their PostgreSQL
performance
monitoring) they discovered the sshd backdoor.
No, I mean that it has been seen in the wild.
When the thread I mentioned appeared, we knew nothing of the
vulnerability, it was March 21st.
apart from all tech details, had the chap that put this
backdoor in the systems been detained yet ?
MarioCCCP <NoliMihiFrangereMentulam@libero.it> wrote:
apart from all tech details, had the chap that put this
backdoor in the systems been detained yet ?
Last reports have been that no one knows who is behind the Jia Tan name
in real life.
So if that info is not "being withheld" then it is reasonable to
presume that no one has been detained yet.
And, if the attack, given its patience and sophistication, is as some surmise, the work of state actors in the employ of their government
(i.e. NSA, CIA, Russia, China, North Korea, etc.) then it is unlikely
that anyone will ever be detained nor will anyone be named.
On 06/04/2024 15:40, Rich wrote:
And, if the attack, given its patience and sophistication, is as some
surmise, the work of state actors in the employ of their government
(i.e. NSA, CIA, Russia, China, North Korea, etc.) then it is unlikely
that anyone will ever be detained nor will anyone be named.
It is at least comforting that if it were, they must not already have
such access, or they would not have bothered.
On 31.03.2024 um 14:25 Uhr Grant Taylor wrote:
N.B. there is a big difference in saying that *BSD / Slackware /
Gentoo (OpenRC) aren't effected by the topic at hand because they
aren't using systemd and saying that they are obviously more secure
because they aren't vulnerable to the topic at hand.
They are not affected because the author of the backdoor maybe intended
to only affect sshd linked to xz or simply forgot that there are
systems that won't be affected by the back door.
Linux distributions with systemd are now the vast majority, so maybe
the author didn't care about some Gentoo or slackware machines.
If he liked, he could affect them too because they most likely have
liblzma installed for other purposes. Although, sshd could be affected,
but various other packages could be if the author intended to do that.
On 2024-04-01 10:44, Marco Moock wrote:
Linux distributions with systemd are now the vast majority, so
maybe the author didn't care about some Gentoo or slackware machines.
Maybe they have certain machines in mind for attacking, and they
know what they run
On 06/04/2024 15:40, Rich wrote:
MarioCCCP <NoliMihiFrangereMentulam@libero.it> wrote:Oh I think someone does..
apart from all tech details, had the chap that put this
backdoor in the systems been detained yet ?
Last reports have been that no one knows who is behind the Jia Tan name
in real life.
So if that info is not "being withheld" then it is reasonable to
presume that no one has been detained yet.
And, if the attack, given its patience and sophistication, is as some
surmise, the work of state actors in the employ of their government
(i.e. NSA, CIA, Russia, China, North Korea, etc.) then it is unlikely
that anyone will ever be detained nor will anyone be named.
It is at least comforting that if it were, they must not already have
such access, or they would not have bothered.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 915 |
| Nodes: | 10 (1 / 9) |
| Uptime: | 28:07:44 |
| Calls: | 12,169 |
| Calls today: | 1 |
| Files: | 186,521 |
| Messages: | 2,234,138 |