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

231–240 of 862 posts

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

#231

Post by im3w1l »

almostnormal wrote: post #126
sneak wrote: post #89

The questions this backdoor raises: - what other ones exist by this same team or similar teams? - how many such teams are operating? - how many such dependencies are vulnerable to such infiltration attacks? what is our industry’s attack surface for such covert operations? I think making a graph of all major network services (apache httpd, postgres, mysql, nginx, openssh, dropbear ssh, haproxy, varnish, caddy, squid,…

Why did they decide to create a backdoor, instead of using a zeroday like everyone else? Why did they implement a fully-featured backdoor and attempted to hide the way it is deployed, instead of deploying something innocent-looking that might as well be a bug if detected? These must have been conscious decisions. The reasons might provide a hint what the goals might have been.

Wild guess, but it could be that whoever was behind this was highly motivated but didn't have the skill required to find zerodays and didn't have the connections required to buy them (and distrusted the come one come all marketplaces I assume must exist).

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

#232

Post by slim »

ghostpepper wrote: post #184
joeyh wrote: post #104

Earlier quoted context omitted.

Since a liblzma backdoor could be used to modify compiler packages that are installed on some distributions, it gets right back to a trusting trust attack. Although initial detection via eg strace would be possible, if the backdoor was later removed or went quiescentit would be full trusting trust territory.

How would this be possible? This backdoor works because lzma is loaded into sshd (by a roundabout method involving systemd). I don't think gcc or clang links lzma.

servers hosting gcc binaries are accessed using ssh

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

#233

Post by mik1998 »

dolmen wrote: post #182
mik1998 wrote: post #113

Earlier quoted context omitted.

I did my own research. If you look at the git repository commit log and some mailing list messages, you will see that the author ("Jia Tan", fake name) speaks impeccable English (already lessens the chance of being a Chinese operative), however he commits in the +0800 time zone (Beijing). He works during Chinese holidays and doesn't work during Western holidays. However, the times don't make sense: It looks like he w…

Do you have some scripts publicly available to reproduce your research?

I used the git repo at https://git.phial.org/d6/xz-analysis-mirror/commits/branch/m... and simply did

  git log --format=%cd --author="Jia Tan"
and then processed it a bit with gnuplot. Should not be difficult to reproduce this graph, but I am not too much of a gnuplot wizard so I first preprocessed this into some different files in a REPL. Don't have the full code of what I did but it should not be difficult to reproduce, just parse the dates and look at the hours.

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

#234

Post by dolmen »

1oooqooq wrote: post #101
wiktor-k wrote: post #22

> OpenSSH certs are weird in that they include the signer's public key. OpenSSH signatures in general contain signer's public key, which I personally think it's not weird but rather cool since it allows verifying the signature without out of the band key delivery (like in OpenPGP). The authentication of the public key is a separate subject but at least some basic checks can be done with an OpenSSH signature only.

> cool since it allows verifying the signature without out of the band key delivery hope you do key selection sanitization instead of the default (nobody does). otherwise you're accepting random keys you have laying around (like github) when logging to secret.example.com

Using an SSH key used with GitHub for other purposes than GitHub is not a good practice (even if it's common).

https://github.com/dolmen/github-keygen

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

#235

Post by kmeisthax »

greyface- wrote: post #43
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.

I understand the impulse to seek justice, but what crime have they committed? It's illegal to gain unauthorized access, but not to write vulnerable code. Is there evidence that this is being exploited in the wild?

If CFAA doesn't get this guy behind bars then the CFAA is somehow even worse. Not only is it an overbroad and confusing law, it's also not broad enough to actually handcuff people who write malicious code.

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

#236

Post by BlueFalconHD »

1oooqooq wrote: post #97
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.

easy there. calling the cops on the NSA might be treason or something

Like that spiderman meme, it's all the NSA

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

#237

Post by transpute »

treasy wrote: post #194
semiquaver wrote: post #100

Earlier quoted context omitted.

Could you explain how SELinux could ever sandbox against RCE in sshd? Its purpose is to grant login shells to arbitrary users, after all.

You can definitely prevent a lot of file/executable accesses via SELinux by running sshd in the default sshd_t or even customizing your own sshd domain and preventing sshd from being able to run binaries in its own domain without a transition. What you cannot prevent though is certain things that sshd _requires_ to function like certain capabilities and networking access. by default sshd has access to all files in /h…

https://news.ycombinator.com/item?id=39879559

> Libselinux pulls in liblzma too

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

#238

Post by undersuit »

legobmw99 wrote: post #221
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.

Why would open source models make this scenario you are painting better?

Because in the closed source model the frustrated developer that looked into this SSH slowness submits a ticket for the owner of the malicious code to dismiss.

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

#239

Post by quotemstr »

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.

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 reproducible from a known git hash. Minimize dependencies. Run whole programs with minimal privileges.

Oh, and finally support SHA2 in git to forever forestall some kind of preimage attack against a git commit hash.

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

#240

Post by kbolino »

sweetjuly wrote: post #228
kbolino wrote: post #179

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. However, you could only really sandbox sshd-as-root. In order for sshd to do its job, it does need to be able to masquerade as arbitrary non-root users. That's still pretty bad but generally not "undetectably alter the operating system or firmware" bad.

>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.
Post reply on HN