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

321–330 of 862 posts

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

#321

Post by cryptonector »

plg94 wrote: post #129
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…

I don't think we know what exactly this does, yet. I can only answer one of those questions, as far as I understand the "unreplayable" part is refering to this: > Apparently the backdoor reverts back to regular operation if the payload is malformed or *the signature from the attacker's key doesn't verify*. emphasis mine, note the "signature of the attacker's key". So unless that key is leaked, or someone breaks the R…

I don't understand yet where the "unreplayable" part comes from, but this isn't it.

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

#322

Post by redox99 »

concordDance wrote: post #282
1oooqooq wrote: post #97

Earlier quoted context omitted.

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

I would have thought NSA would have hardware/firmware backdoor everywhere and wouldn't need this.

Probably not for fully Chinese hardware. Although this backdoor is only x86 so it still wouldn't work there.

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

#324

Post by filleokus »

pas wrote: post #261
formerly_proven wrote: post #159

Earlier quoted context omitted.

No

... why?

Did the artefact produced [0] for fussing even include the backdoored .so? My understanding was that the compromised build-scripts had measures to only run when producing deb/rpms.

https://github.com/google/oss-fuzz/blob/5f70676a6c9050b9cb68...

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

#325

Post by pvg »

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.

Chad NSA

It's called the ANS is Chad.

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

#326

Post by refulgentis »

XorNot wrote: post #288
raggi wrote: post #154

Earlier quoted context omitted.

There is one possible time pressure involved, which is that libsystemd dropped the liblzma dependency

Absolutely no intelligence agency would look at a successful compromise where they have a highly positioned agent in an organization like this, and burn them trying to rush an under-developed exploit in that would then become not useful almost immediately (because the liblzma dependency would be dropped next distro upgrade cycle). If you had a human-asset with decision making authority and trust in place, then as fun…

No true Scotsman

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

#327

Post by cryptonector »

creato wrote: post #311

One of the takeaways from this to me is that there is way too much sketchy bullshit happening in critical system software. Prebuilt binary blobs [1]? Rewriting calls to SIMD enhanced versions at runtime [2]? Disabling sanitizers [3]? Incomprehensible build scripts [4]? All of this was either at least strongly frowned upon, if not outright unacceptable, on every project I've ever worked on, either professionally or fo…

> Rewriting calls to SIMD enhanced versions at runtime?

That's something that's been done for decades. It's pretty normal. What's not normal is for that to get re-done after startup. That is, one library should not be able to get that resolution process to be re-done after it's been done once. Malicious code that knows the run-time linker-loader's data structures could still re-resolve things anyways, which means that even removing this feature altogether from the run-time linker-loader wouldn't prevent this particular aspect of this attack.

I.e., you're barking up the wrong tree with (2).

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

#328

Post by treasy »

semiquaver wrote: post #304
kbolino wrote: post #240

Earlier quoted context omitted.

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.

I’ll admit to not being an expert in SELinux, but it seems like an impossibly leaky proposition. Root can modify systemd startup files, so just do that in a malicious way and reboot the system. that context won’t be propagated. And if you somehow prohibit root from doing that by SELinux policy then you end up with a system that can’t actually be administered. [edit: sibling sweetjuly said it better than I could. I do…

Selinux domains are uncoupled from Linux users. If sshd does not have Selinux permissions to edit those files it will simply be denied. Even if sshd is run as root

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

#329

Post by Fnoord »

rdtsc wrote: post #98
asveikau wrote: post #27

I have found it irritating how in the community, in recent years, it's popular to say that if a project doesn't have recent commits or releases that something is seriously wrong. This is a toxic attitude. There was nothing wrong with "unmaintained" lzma two years ago. The math of the lzma algorithm doesn't change. The library was "done" and that's ok. The whiny mailing list post from the sock puppet, complaining abou…

Excellent point. I believe that's coming from corporate supply chain attack "response" and their insistence on making hard rules about "currency" and "activity" and "is maintained" pushes this kind of crap. Attackers know this as well. It doesn't take much to hang around various mailing lists and look for stuff like this: https://www.mail-archive.com/xz-devel@tukaani.org/msg00567.h... > (Random user or sock puppet) I…

> 7-Zip supports .xz and keeping its developer Igor Pavlov informed about format changes (including new filters) is important too.

I've always found that dev's name to tilt me.

Funnily enough, the Chinese name was no reason to investigate. It was a performance issue.

Also, to the discussion that a distribution was targeted. Jia advocated Fedora to upgrade to 5.6.x. Fedora is the precursor for RHEL.

Together with the backdoor not working when LANG not set (USA).

Those are two details suggesting the target was USA. Though either or both could've been part of the deception.

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

#330

Post by refulgentis »

pbhjpbhj wrote: post #185
semiquaver wrote: post #108

Earlier quoted context omitted.

CFAA covers this. Its a crime to > knowingly [cause] the transmission of a program, information, code, or command, and as a result of such conduct, intentionally causes damage without authorization, to a protected computer; Where one of the definitions of “protected computer” is one that is used in interstate commerce, which covers effectively all of them.

It seems like the backdoor creates the potential to "cause damage" but doesn't [provably?] cause damage per se ? The author of the backdoor doesn't themselves "[cause] the transmission of a program ...". Others do the transmission. Seems weak, unless you know of some precedent case(s)?

Law isn't code. If someone finds precedent, there will be a way to argue it doesn't cover this specific scenario. They call this conversational process "hypos" in law school, and this fundamental truth is why you never hear of a lawyer being stumped as to how to defend a client.

Ultimately, the CFAA will get it done if it gets that far, armchair lawyering aside.

To pressure test this fully, since this can be caricatured as "we can punish degenerate behavior as needed", which isn't necessarily great: it's also why there's a thin line between a authoritarian puppet judiciary and a fair one.

Post reply on HN