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

291–300 of 862 posts

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

#291

Post by dboreham »

pcthrowaway wrote: post #170
jmward01 wrote: post #39

Where is the law enforcement angle on this? This individual/organization needs to be on the top of every country's most wanted lists.

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.

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

#292

Post by everybackdoor »

raggi wrote: post #150
x0x0 wrote: post #143

Earlier quoted context omitted.

[flagged]

Think whatever you shall about systemd of course, but please stop with the blind belief mud slinging: - systemd didn't create the patch to include libsystemd, distros did - current systemd versions already remove liblzma from their dependencies, the affected distros are behind on systemd updates though - you can implement notify in standalone code in about the same effort as it takes to use the dependency, there wasn…

[flagged]

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

#293

Post by chr-s »

aaronmdjones wrote: post #245
pcthrowaway wrote: post #195

Has anyone proposed a name for this exploit yet?

CVE-2024-3094

"Backdoor in upstream xz/liblzma leading to ssh server compromise"[0] isn't bad either.

[0]https://www.openwall.com/lists/oss-security/2024/03/29/4

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

#294

Post by nurple »

loumf wrote: post #193
gouggoug wrote: post #160

Earlier quoted context omitted.

For people like me whose C knowledge is poor, can you explain why this dot is significant? What does it do in actuality?

You are looking at a makefile, not C. The C code is in a string that is being passed to a function called `check_c_source_compiles()`, and this dot makes that code not compile when it should have -- which sets a boolean incorrectly, which presumably makes the build do something it should not do.

Interesting that validating the failure reason of an autotools compile check could be a security mitigation...

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

#295

Post by bee_rider »

pas wrote: post #219
martinohansen wrote: post #207

Imagine a future where state actors have hundreds of AI agents fixing bugs, gaining reputation while they slowly introduce backdoors. I really hope open source models succeed.

... if we want security it needs trust anyway. it doesn't matter if it's amazing Code GPT or Chad NSA, the PR needs to be reviewed by someone we trust. it's the trust that's the problem. web of trust purists were right just ahead of the time.

It would actually be sort of interesting if multiple adversarial intelligence agencies could review and sign commits. We might not trust any particular intelligence agency, but I bet the NSA and China would both be interested in not letting much through, if they knew the other guy was looking.

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

#296

Post by cryptonector »

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.

This is what PrivSep was supposed to do. sshd could fork an unprivileged and restricted process to do the signature validation, I suppose.

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

#298

Post by nurple »

quotemstr wrote: post #239
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.

Doesn't matter. This is a supply chain attack, not a vulnerability arising from a bug. All sandboxing the certificate parsing code would have done is make the author of the backdoor do a little bit more work to hijack the necessarily un-sandboxed supervisor process. Applying the usual exploit mitigations to supply chain attacks won't do much good. What will? Kill distribution tarballs. Make every binary bit for bit r…

Oh boy, do I have the packaging system for you!

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

#299

Post by cryptonector »

treasy wrote: post #216
asveikau wrote: post #206

Earlier quoted context omitted.

I thought that OpenSSH's sshd already separates itself into a privileged process and a low-privilege process. I don't know any details about that. Here's what Google showed me for that: https://github.com/openssh/openssh-portable/blob/master/READ...

If you look at the diagram of privsep, the authentication process is part of the privileged binary, which is where this RCE lives http://www.citi.umich.edu/u/provos/ssh/priv.jpg

The signature validation could be moved into an unprivileged process forked from that one.

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

#300

Post by sweetjuly »

kbolino wrote: post #240
sweetjuly wrote: post #228

Earlier quoted context omitted.

>Even though sshd must run as root (in the usual case), it doesn't need unfettered access to kernel memory, most of the filesystem, most other processes, etc This is sort of overlooking the problem. While true, the processes spawned by sshd do need to be able to do all these things and so even if you did sandbox it, preserving functionality would all but guarantee an escape is trivial (...just spawn bash?).

SELinux context is passed down to child processes. If sshd is running as confined root (system_u:system_r:sshd_t or similar), then the bash spawned by RCE will be too. Even if sshd is allowed to masquerade as an unconfined non-root user, that user will (regardless of SELinux) be unable to read or write /dev/kmem, ignore standard file permissions, etc.

That's my point though--users expect to be able to do those things over ssh. Sandboxing sshd is hard because its child processes are expected to be able to do anything that an admin sitting at the console could do, up to and including reading/writing kernel memory.
Post reply on HN