Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Backdoor in upstream xz/liblzma leading to SSH server compromise

openwall.com

Post reply on HN
Print view View original

661–670 of 1001 posts

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#661

Post by robocat »

masklinn wrote: post #464
sroussey wrote: post #426

Earlier quoted context omitted.

OMG: look at the other contributions. He is trying to take over projects and pushing some change to sha256 in a hundred projects. Example: https://github.com/duesee/imap-flow/issues/96

This guy's interactions seem weird but it might just be because of the non-native english or a strange attitude, or he's very good at covering his track e.g. found a cpython issue where he got reprimanded for serially opening issues: https://github.com/python/cpython/issues/115195#issuecomment... But clicking around he seems to mostly be interacting with interest around these bits e.g. https://github.com/python/cpyth…

> dickriding

https://www.urbandictionary.com/define.php?term=Dickriding

I guess I'm not in the right demographic to know the term.

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#662

Post by crest »

gopher_space wrote: post #152
eigenvalue wrote: post #129

Earlier quoted context omitted.

Every single commit this person ever did should immediately be rolled back in all projects.

It's weird and disturbing that this isn't the default perspective.

Too much fallout.

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#664

Post by LispSporks22 »

rwmj wrote: post #42

Very annoying - the apparent author of the backdoor was in communication with me over several weeks trying to get xz 5.6.x added to Fedora 40 & 41 because of it's "great new features". We even worked with him to fix the valgrind issue (which it turns out now was caused by the backdoor he had added). We had to race last night to fix the problem after an inadvertent break of the embargo. He has been part of the xz proj…

Nice. I worked on a Linux disto when I was a wee lad and all we did was compute a new md5 and ship it.

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#665

Post by jnxx »

jnxx wrote: post #477
pfortuny wrote: post #159

Unfortunately, this is how good bad actors work: with a very long-term point of view. There is no “harmless” project any more.

And, Joey Hess has counted at least 750 commits to xz from that handle. https://hachyderm.io/@joeyh/112180715824680521 This does not look trust-inspiring. If the code is complex, there could be many more exploits hiding.

If this is a conspiracy or a state-sponsored attack, they might have gone specifically for embedded devices and the linux kernel. Here archived from tukaani.org:

https://web.archive.org/web/20110831134700/http://tukaani.or...

> XZ Embedded is a relatively small decompressor for the XZ format. It was developed with the Linux kernel in mind, but is easily usable in other projects too.

> *Features*

> * Compiled code 8-20 KiB

> [...]

> * All the required memory is allocated at initialization time.

This is targeted at embedded and real-time stuff. Could even be part of boot loaders in things like buildroot or RTEMS. And this means potentially millions of devices, from smart toasters or toothbrushes to satellites and missiles which most can't be updated with security fixes.

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#666

Post by inetknght »

w4ffl35 wrote: post #625
jonathanspw wrote: post #154

Earlier quoted context omitted.

Yesterday sure was fun wasn't it :p Thanks for all your help/working with me on getting this cleaned up in Fedora.

Is it normal that when I try to uninstall xz it is trying to install lzma?

It means that `xz` was depended upon by something that depends on eg "xz OR lzma"

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#667

Post by kn100 »

Here's a handy bash script I threw together to audit any docker containers you might be running on your machine. It's hacky, but will quickly let you know what version, if any, of xz, is running in your docker containers.

``` #!/bin/bash

# Get list of all running Docker containers containers=$(docker ps --format "{{.Names}}")

# Loop through each container for container in $containers; do # Get container image image=$(docker inspect --format='{{.Config.Image}}' "$container")

    # Execute xz --version inside the container
    version=$(docker exec "$container" xz --version)

    # Write container name, image, and command output to a text file
    echo "Container: $container" >> docker_container_versions.txt
    echo "Image: $image" >> docker_container_versions.txt
    echo "xz Version:" >> docker_container_versions.txt
    echo "$version" >> docker_container_versions.txt
    echo "" >> docker_container_versions.txt
done

echo "Output written to docker_container_versions.txt" ```

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#668

Post by swagmoney1606 »

yieldcrv wrote: post #105
rwmj wrote: post #42

Very annoying - the apparent author of the backdoor was in communication with me over several weeks trying to get xz 5.6.x added to Fedora 40 & 41 because of it's "great new features". We even worked with him to fix the valgrind issue (which it turns out now was caused by the backdoor he had added). We had to race last night to fix the problem after an inadvertent break of the embargo. He has been part of the xz proj…

I wonder who the target was!

Probably less of an individual and more of an exploit to sell.

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#669

Post by StressedDev »

haolez wrote: post #467

I'm not trying to troll, but I'm wondering if a distro like Gentoo is less susceptible to such attacks, since the source code feels more transparent with their approach. But then again, it seems that upstream was infected in this case, so I'm not sure if a culture of compiling from source locally would help.

It is not going to make a difference. If you run malicious code, you will get hacked. Compiling the code yourself does not prevent the code from being malicious.

The one it might help is it might make it easier to find the back door once you know there is one.

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#670

Post by cryptonector »

BobbyTables2 wrote: post #629

Why doesn’t GitHub force “releases” to be a simple repo tarball for sources and with binaries from GitHub actions or such… I find it incredibly ironic that a “version control” site gives no assurance of reproducible builds (nor reproducible source!!) The real villain is not the perpetrator, it is Microsoft, and it is all of us.

Because then for autoconf codebases you have to commit `./configure` or you have to require that users have autoconf installed and run `autoreconf -fi` first.

Maybe autoconf-using projects should really just require that users have autoconf installed.

Not that that would prevent backdoors, mind you.

Post reply on HN