this post was submitted on 29 Mar 2024
519 points (99.1% liked)

Linux

48679 readers
393 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] flying_sheep@lemmy.ml -3 points 8 months ago (2 children)

Backdoor only gets inserted when building RPM or DEB. So while updating frequently is a good idea, it won't change anything for Arch users today.

[–] SavvyBeardedFish@reddthat.com 17 points 8 months ago (2 children)
[–] flying_sheep@lemmy.ml 13 points 8 months ago

No, read the link you posted:

Arch does not directly link openssh to liblzma, and thus this attack vector is not possible. You can confirm this by issuing the following command:

ldd "$(command -v sshd)"

However, out of an abundance of caution, we advise users to remove the malicious code from their system by upgrading either way.

[–] progandy@feddit.de 3 points 8 months ago* (last edited 8 months ago)

I think that was a precaution. The malicious build script ran during the build, but the backdoor itself was most likely not included in the resuling package as it checked for specific packaging systems.

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

[–] corsicanguppy@lemmy.ca 5 points 8 months ago (3 children)

when building RPM or DEB.

Which ones? Everything I run seems to be clear.

https://access.redhat.com/security/cve/CVE-2024-3094

| Products / Services | Components | State | |


|


|


|
| Enterprise Linux 6 | xz | Not affected | | Enterprise Linux 7 | xz | Not affected | | Enterprise Linux 8 | xz | Not affected | | Enterprise Linux 9 | xz | Not affected |

(and thus all the bug-for-bug clones)

[–] progandy@feddit.de 3 points 8 months ago

Those getting the most recent software versions, so nothing that should be running in a server.

[–] Laser@feddit.de 2 points 8 months ago

Fedora 41, Fedora Rawhide, Debian Sid are the currently known affected ones AFAIK.

[–] flying_sheep@lemmy.ml 1 points 8 months ago

I think it needs to be

  • rolling release (because it was caught so quickly that it hasn't made its way into any cadence based distro yet)
  • using the upstream Makefile task to build a RPM or DEB (because the compromised build script directly checks for that and therefore doesn't trigger for a destdir build like Gentoo’s or Arch’s)
  • using the upstream provided tarball as opposed to the one GitHub provides, or a git clone (because only that contains the compromised Makefile, running autotools yourself is safe)

Points 1 and 2 mean that only rolling release RPM and DEB distros like Debian Sid and Fedora are candidates. I didn't check if they use the Makefile and the compromised tarballs.