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

361–370 of 862 posts

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

#361

Post by dhx »

jeroenhd wrote: post #12
junon wrote: post #3

EDIT: Here's some more RE work on the matter. Has some symbol remapping information that was extracted from the prefix trie the backdoor used to hide strings. Looks like it tried to hide itself even from RE/analysis, too. https://gist.github.com/smx-smx/a6112d54777845d389bd7126d6e9... Full list of decoded strings here: https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01 -- For someone unfamiliar with openssl…

> 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 before the process is then executed. seccomp filters are inherited by child processes, which can then only further restrict privileges but not expand upon the inherited privileges. openssh-portable on Linux does apply seccomp filters to child processes but this is useless in this attack scenario because sshd is backdoored by the xz library, and the backdoored library can just disable/change those seccomp filters before sshd is executed.

sshd is particularly challenging to sandbox because if you were to restrict the namespace and apply strict seccomp filters via systemd-nspawn, a user gaining a root shell via sshd (or wanting to sudo/su as root) is then perhaps prevented from remotely debugging applications, accessing certain filesystems, interacting with network interfaces, etc depending on what level of sandboxing is applied from systemd-nspawn. This choice is highly user dependent and there are probably only limited sane defaults for someone who has already decided they want to use sshd. For example, sane defaults could include creating dedicated services with sandboxing tailored just for read-only sftp user filesystem access, a separate service for read/write sftp user filesystem access, sshd tunneling, unprivileged remote shell access, etc.

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

#363

Post by lazide »

qudat wrote: post #85
codetrotter wrote: post #29

Earlier quoted context omitted.

It’s pretty funny how a bunch of people come piling reaction emojis onto the comments in the PR, after it has all become publicly known. I’m like.. bro, adding reaction emojis after the fact as if that makes any sort of difference to anything.

Feels almost like tampering with evidence at a crime scene

It’s just adding your initials on the tunnel someone famous just died in.

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

#364

Post by tialaramex »

swid wrote: post #290
rmi_ wrote: post #274

Earlier quoted context omitted.

> So unless that key is leaked But, just for replayability, we could "patch" the exploit with a known key and see what it does, don't we?

Replayability means something different in this context. First, we do know the backdoor will pass the payload to system, so in general it is like an attacker has access to bash, presumably as root since it is sshd. Replayability means, if someone were to catch a payload in action which did use the exploit, you can’t resend the attacker’s data and have it work. It might contain something like a date or other data spec…

> It might contain something like a date or other data specific only to the context it came from.

In all these modern protocols, including SSHv2 / SecSH (Sean Connery fans at the IETF evidently) both parties deliberately introduce random elements into a signed conversation as a liveness check - precisely to prevent replaying previous communications.

TLS 1.3's zero round-trip (ORT) mode cannot do this, which is why it basically says you'd better be damn sure you've figured out exactly why it's safe to use this, including every weird replay scenario and why it's technically sound in your design or else you must not enable it. We may yet regret the whole thing and just tell everybody to refuse it.

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

#366

Post by Denvercoder9 »

junon wrote: post #263
chatmasta wrote: post #107

Can someone explain succinctly what the backdoor does ? Do we even know yet? The backdoor itself is not a payload, right? Does it need a malicious archive to exploit it? Or does it hook into the sshd process to listen for malicious packets from a remote attacker? The OP makes it sound like an attacker can send a malicious payload in the pre-auth phase of an SSH session - but why does he say that an exploit might neve…

Siblings saying "we don't know" haven't really groked the post I don't think. If I'm understanding the thread correctly, here's a (not so) succinct explanation. Please, if you know better than I do, correct me if I've made an error in my understanding. `system()` is a standard C function that takes a string as input and runs it through `sh`, like so: sh -c "whatever input" It's used as a super rudimentary way to run…

> Siblings saying "we don't know" haven't really groked the post I don't think.

The reason for saying "we don't know" is not that we don't understand what's detailed in TFA, but that the backdoor embeds a 88 kB object file into liblzma, and nobody has fully reverse engineered and understood all that code yet. There might be other things lurking in there.

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

#367

Post by tialaramex »

denysvitali wrote: post #269
BlueFalconHD wrote: post #222

Earlier quoted context omitted.

It would be really cool if in 20 years when we have quantum computers powerful enough we could see what this exploit does.

My understanding is that we know somehow already what the exploit allows the attacker to do - we just can't reproduce it because we don't have their private key. Technically, we can modify the backdoor and embed our own public key - but there is no way to probe a random server on the internet and check if it's vulnerable (from a scanner perspective). In a certain way it's a good thing - only the creator of the backdo…

It's a NOBUS (Nobody But Us can use it) attack. The choice to use a private key means it's possible that even the person who submitted the tampered code doesn't have the private key, only some other entity controlling them does.

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

#368

Post by golergka »

quatrefoil wrote: post #135
sega_sai wrote: post #95

One have question on this is, if the backdoor would not been discovered due to performance issue (which was as I understood it purely an oversight/fixable deficiency in the code), what are the chances of discovering this backdoor later, or are there tools that would have picked it up? Those questions are IMO relevant to understand if this kind of backdoor is the first one of the kind, or the first one that was uncove…

If the exploit wasn't baing used, the odds would would be pretty low. They picked the right place to bury it (i.e., effectively outside the codebase, where no auditor ever looks). That said, if you're not using it, it defeats the purpose. And the more you're using it, the higher the likelihood you will be detected down the line. Compare to Solarwinds.

> That said, if you're not using it, it defeats the purpose.

Not always. Weapons of war are most useful when you don't have to actually use them, because others know that you have it. This exploit could be used sparingly to boost a reputation of a state-level actor. Of course, other parties wouldn't know about this particular exploit, but they would see your cyber capabilities in the rare occasions where you decided to use it.

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

#369

Post by dannyw »

dboreham wrote: post #291
pcthrowaway wrote: post #170

Earlier quoted context omitted.

Based on the level of sophistication being alluded to, I'm personally inclined to assume this is a state actor, possible even some arm of the U.S. govt.

To me it seems too clumsy to be USG. They seem to prefer back doors that are undetectable or hide in plain sight. But it might be an NSA op designed to instigate a much needed serious examination of the supply chain.

Remember how bad, slow, and obvious Dual_EC_DRNG was?

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

#370

Post by tigerlily »

As a de facto maintainer of an obscure open source game, I see devs come and go. I just merge all the worthwhile contributions. Some collaborators go pretty deep with their features, with a variety of coding styles, in a mishmash of C and C++. I'm not always across the implementation details, but in the back of my mind I'm thinking, man, anyone could just code up some real nasty backdoor and the project would be screwed. Lucky the game is so obscure and the attack surface minuscule, but it did stop me from any temptation to sign Windows binaries out of any sense of munificence.

This xz backdoor is just the most massive nightmare, and I really feel for the og devs, and anyone who got sucked in by this.

Post reply on HN