The xz backdoor was initially caught by a software engineer at Microsoft. He noticed 500ms lag and thought something was suspicious.
— vx-underground (@vxunderground) March 30, 2024
This is the Silver Back Gorilla of nerds. The internet final boss. pic.twitter.com/6IyJQ2tpMm
-
For a complete changelog: https://github.com/ankitects/anki/releases/tag/24.04
-
-
-
With over 750 commits over the last 2 years, previous xz versions are also not safe.
https://boehs.org/node/everything-i-know-about-the-xz-backdoor
-
- All supported FreeBSD releases include versions of xz that predate the affected releases.
- The main, stable/14, and stable/13 branches do include the affected version (5.6.0), but the backdoor components were excluded from the vendor import.
- Additionally, FreeBSD does not use the upstream’s build tooling, which was a required part of the attack. Lastly, the attack specifically targeted x86_64 Linux systems using glibc.
- The FreeBSD ports collection does not include xz/liblzma.
https://lists.freebsd.org/archives/freebsd-security/2024-March/000248.html
-
You can even use CSV format thus making import of multiple card faster
-
maybe contained the malicious xz package …
-
Seems pretty serious! Update your systems now !!!
The vulnerability affects xz packages prior to version 5.6.1-2 (specifically 5.6.0-1 and 5.6.1-1).
Andres Freund noticed odd symptoms around liblzma (part of the xz package) on Debian sid installations over the last weeks (logins with ssh taking a lot of CPU, valgrind errors) and concluded that the xz package has been backdoored.
The backdoor is present in the tarballs released upstream and contains the following line (originally not present in the source code):
After the update:
Running ldd (shared libraries utility) to ensure no linkage between openssh and liblzma.
https://www.openwall.com/lists/oss-security/2024/03/29/4
https://archlinux.org/news/the-xz-package-has-been-backdoored
-
“cp, mv, install, cat, and split commands can now read/write a minimum of 256KiB at a time. Previously there was a 128KiB minimum while this has been doubled in order to enhance the throughput of Coreutils on modern systems. The throughput with Coreutils 9.5 thanks to this change increases by 10~20% when reading cached files on modern systems. The benefit comes from reducing system call overhead. This default I/O size update was last adjusted a decade ago.”
This change was introduced in this commit:
https://lists.gnu.org/archive/html/info-gnu/2024-03/msg00006.html
-
/root 