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

XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."

bsky.app

Post reply on HN
Print view View original

601–610 of 862 posts

Re: XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."

#601

Post by geggo98 »

tambourine_man wrote: post #425

I’d like to know what we mortals – those that run Ubuntu LTS on VMs, for instance — need to do, if anything.

My suggestion: Put your SSH behind WireGuard and/or behind a jump host (with only port forwarding allowed, no shell). If you don’t have a separate host, use a Docker container.

If you use a jump host, consider a different OS (e.g., BSD vs Linux). Remember this analogy with slices of Swiss cheese used during the pandemics? If one slice has a hole, the next slice hopefully won’t have a hole on the same position. The more slices you have, the better for you.

Although for remote management, you don’t want to have too many “slices” you have to manage and that can fail.

Re: XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."

#602

Post by kortilla »

lettergram wrote: post #393

What I’d like to understand is it’s proven intentional? My understanding is it was a few added characters in a header file. I can’t tell you the number of times I was tired and clicked an extra key before committing, or my cat walked across the keyboard while I was out of the room.

You should read up on the attack. The few characters were part of avoiding a specific case of detection. The back door is very large, is only added during tar build, and happens to only work when a special key is presented.

Re: XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."

#603

Post by mr_mitm »

armada651 wrote: post #577
AnonHP wrote: post #532

Earlier quoted context omitted.

> Nitpick, but no it shouldn’t. The HASH of your password is recorded. You never submit your password, you submit that hash and they compare it. Nitpick, but the password is submitted as-is by most client applications, and the server hashes the submitted password and compares it with the hash it has (of course, with salting).

> Nitpick, but the password is submitted as-is by most client applications, and the server hashes the submitted password and compares it with the hash it has (of course, with salting). I never understood why clients are coded this way. It's trivially easy to send the salt to the client and have it do the hashing. Though I guess it doesn't really improve security in a lot of cases, because if you successfully MITM a w…

> I never understood why clients are coded this way.

Because it makes things less secure. If it was sufficient to send the hash to the server to authenticate, and the server simply compares the hash sent by the user with the hash in its database, then the hash as actually the password. An attacker doesn't need to know the password anymore, as the hash is sufficient.

Hashing was introduced precisely because some vulnerabilities allow read access to the database. With hashed passwords, the attacker in such a situation has to perform a password guessing attack first to proceed. If it was sufficient to send the hash for authentication, the attacker would not need to guess anything.

Re: XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."

#604

Post by nottorp »

dhx wrote: post #361
jeroenhd wrote: post #12

Earlier quoted context omitted.

> However, since this is an RCE in the context of e.g. an sshd process itself, this means that sshd running as root would allow the payload to itself run as root. With the right sandboxing techniques, SELinux and mitigations could prevent the attacker from doing anything with root permissions. However, applying a sandbox to an SSH daemon effectively is very difficult.

sshd is probably the softest target on most systems. It is generally expected (and setup by default) so that people can gain a root shell that provides unrestricted access. sshd.service will typically score 9.6/10 for "systemd-analyze security sshd.service" where 10 is the worst score. When systemd starts a process, it does so by using systemd-nspawn to setup a (usually) restricted namespace and apply seccomp filters…

So for all practical purposes you can't sandbox ssh on a developer's machine much.

Re: XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."

#605

Post by bostik »

dolmen wrote: post #125

git.tukaani.org runs sshd. If that sshd was upgraded with the xz backdoor, we cannot exclude that the host was compromised as it could be have been a obvious target for the backdoor author.

Rather unlikely. The bad actor never had access to git.tukaani.org, and the sshd version running on that host is:

    SSH-2.0-OpenSSH_7.9p1 Debian-10+deb10u3
That is, a stable Debian release. Definitely not one with liblzma5:5.6.x

Re: XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."

#606

Post by daurentius523 »

tomoyoirl wrote: post #112
sneak wrote: post #92

Earlier quoted context omitted.

Nah, the CIA assassinates people in MLAT zones all the time. The laws that apply to you and I don’t apply to the privileged operators of the state’s prerogatives. We don’t even know that this specific backdoor wasn’t the NSA or CIA. Assuming it was a foreign intelligence service because the fake name was asian-sounding is a bit silly. The people who wrote this code might be sitting in Virginia or Maryland already.

> Virginia or Maryland Eastern Europe, suggest the timestamp / holiday analysts. https://rheaeve.substack.com/p/xz-backdoor-times-damned-time...

Eastern Europe - 25th? Not 24th?

Re: XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."

#608

Post by rany_ »

adtac wrote: post #560
rany_ wrote: post #286

If my server doesn't have any RSA public keys in its authorized_keys, only ed25519 keys; does this backdoor just not work?

It will still work if the connecting client offers a RSA key. The only real way to be sure it's not on your system is if your liblzma version is strictly less than 5.6.0 (first infected version): ls -al $(ldd $(which sshd) | grep lzma | awk '{ print $3 }')

Thanks for the reply, I was just curious because `RSA_public_decrypt` threw me off.

Re: XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."

#609

Post by rany_ »

keiba wrote: post #555
rany_ wrote: post #286

If my server doesn't have any RSA public keys in its authorized_keys, only ed25519 keys; does this backdoor just not work?

This backdoor does not care about any of the authorisation configuration set by the user. It is executed before that step. So just make sure you are not affected.

It was just that it hooks to `RSA_public_decrypt` which threw me off, I didn't really understand this backdoor much. I only have one Debian sid machine which was vulnerable and accessible via a public IPv4 ssh, I'm not sure if I should just wipe it.

Re: XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."

#610

Post by kzrdude »

It's weird now that "it's right there in the open",

Listed among the most recent commits there is "update two test files" https://git.tukaani.org/?p=xz.git;a=commitdiff;h=6e636819e8f...

And it's kind of smart to attack a compression library - you have plausible deniability for these opaque binary blobs - they are supposedly test cases, but in reality encode parts of the backdoor.

Post reply on HN