|
|||
Linux xv issue, *BSDs are fine
For people also using Linux, a xv/liblzma backdoor found, info here:
https://gist.github.com/thesamesam/2...e9ee78baad9e27
__________________
[t]csh(1) - "An elegant shell, for a more... civilized age." - Paraphrasing Star Wars (tvtropes.org) |
|
|||
|
|
||||
Arch was never affected by CVE-2024-3094. The upgrade advice is precautionary.
EDIT: reference: https://bbs.archlinux.org/viewtopic.php?id=294363
__________________
Para todos todo, para nosotros nada |
|
|||
Awful scary situation.
Some interesting discussion below. https://news.ycombinator.com/item?id=39877267 |
|
||||
The original mail: https://www.openwall.com/lists/oss-s...y/2024/03/29/4
Original xz author's site: https://tukaani.org/xz-backdoor/ From the OpenBSD mailing list (archive): https://marc.info/?l=openbsd-misc&m=171179460913574&w=2 Write up linked from that post: https://lcamtuf.substack.com/p/techn...he-xz-backdoor Quote:
|
|
||||
CVE-2024-3094 is not the entire story — there was a commit that sabotaged sandboxing but it's not used for the known exploit: https://git.tukaani.org/?p=xz.git;a=...58db2c422d9ba7
__________________
Para todos todo, para nosotros nada |
|
|||
Quote:
I think the way BSDs are developed makes these type things harder due to a clear separation between ports and base.
__________________
[t]csh(1) - "An elegant shell, for a more... civilized age." - Paraphrasing Star Wars (tvtropes.org) |
|
|||
Reminds me of the OpenBSD FBI backdoor scare in 2010.
|
|
||||
Quote:
My gut instinct would tell me that such backdoors are more prevalent than we imagine and that the Linux kernel and other commonly used software may already have been compromised years ago. Quote:
I think the big "why" here - as in why this happened - is not something you can answer or solve overnight, or even in a few years. FLOSS projects come without warranty, are often developed by hobbyists in their own time, for free and there is no way you can impose any rules on said projects, without jeopardizing the pillars of FLOSS and arriving at the unfortunate "only tech companies / Big Tech can be trusted to properly audit code and those individuals contributing to that code" conclusion. Except they can't be trusted either. This whole debacle also lends a lot of weight to the long standing OpenBSD philosophy of not trusting any of the software you are installing - by default. |
|
|||
The time it takes to assemble a sophisticated attack vector is substantial. What I would be concerned with is:
1) Does the malicious code duplicate itself and insert itself into the compressed software? 2) Is the malicious code in other software? Is it possible to run a script with diff to look for similar code fragments? |
|
|||
Quote:
that ships as part of GNU gettext was replaced by a modified version that was copied into the release tarball and, importantly, was used to generate a modified configure script. Let's call this stage 0." (from xz port maintainer email a few messages down the thread). Why would they leave around the modified build-to-host.m4 file? It's input to autoconf generating configure with an exploit, so why not revert to the proper one once you've got the compromised configure? Would be that much harder to spot, yes? |
Tags |
backdoor, liblzma, linux, xv |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
xfce4 work fine, but gnome issue | philo_neo71 | OpenBSD Packages and Ports | 10 | 9th September 2016 01:12 AM |
Porting Linux applications to the BSDs | jggimi | Guides | 1 | 3rd August 2011 09:44 PM |
New BSD magazine issue: "BSDs as Servers" | wesley | News | 0 | 1st February 2010 12:31 PM |
hard disk: avail 0 capacity 100% is it fine to use it like this? | gosha | General Hardware | 13 | 17th June 2009 03:53 PM |
Network connection works fine, and then... | snes-addict | OpenBSD General | 8 | 20th October 2008 11:13 PM |