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?
XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."
221–230 of 862 posts
Re: XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."
#222Can 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…
It would be really cool if in 20 years when we have quantum computers powerful enough we could see what this exploit does.
Re: XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."
#223Can 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…
This feels very targeted
Re: XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."
#224SE Linux comment by @poettering, https://news.ycombinator.com/item?id=39867126
> Libselinux pulls in liblzma too and gets linked into tons more programs than libsystemd. And will end up in sshd too (at the very least via libpam/pam_selinux). And most of the really big distros tend do support selinux at least to some level. Hence systemd or not, sshd remains vulnerable by this specific attack.
Devuan comment by @capitainenemo, https://news.ycombinator.com/item?id=39866190
> The sshd in Devuan does link to a libsystemd stub - this is to cut down on their maintenance of upstream packages. However that stub does not link to lzma.
Future proofing, https://gynvael.coldwind.pl/?lang=en&id=782
Stage 2 "extension" mechanism
This whole thing basically looks like an "extension/patching" system that would allow adding future scripts to be run in the context of Stage 2, without having to modify the original payload-carrying test files. Which makes sense, as modyfing a "bad" and "good" test files over and over again is pretty suspicious. So the plan seemed to be to just add new test files instead, which would have been picked up, deciphered, and executed.Re: XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."
#225Earlier quoted context omitted.
Yeah these types of security issues will be used by politicians to force hardware makers to lockdown hardware, embed software in chips. The go fast startups habit of “import the world to make my company products” is a huge security issue IT workers ignore. The only solution politics and big tech will chase is obsolete said job market by pulling more of the stack into locked down hardware, with updates only allowed to…
The NSA demands that Intel and AMD provide backdoor ways to turn off the IME/PSP, which are basically a small OS running in a small processor inside your processor. So the precedent is that the government wants less embedded software in their hardware, at least for themselves. If we relied on gadget vendors to maintain such software, I think we can just look at any IoT or router manufacturer to get an idea of just ho…
What does the IME or PSP do?
Re: XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."
#226Has anyone proposed a name for this exploit yet?
rxzec
Re: XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."
#227I am wondering if reinstalling the entire Archlinux installation would be a wise choice.
Arch Linux uses a native/unpatched version of OpenSSH without dependency on libsystemd and thus without dependency on xz-utils, resulting in no exploitable code path. This means that at least the currently talked about vulnerability/exploit via SSH did presumably not work on Arch. Disclaimer: This is my understanding of the currently circulating facts. Additional fallout might be possible, as the reverse engineering…
there are other ways for liblzma to get into ssh (via PAM and libselinux)
Re: XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."
#228Earlier 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.
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?).
Re: XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."
#229Earlier quoted context omitted.
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…
This feels very targeted
Or very untargeted. Something intended just to lay dormant by chance if succeeded...
It is very good backdoor to have if you at whatever time have dozens of options. See sshd running, test this you are done if it works, if not move to something else.
Re: XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."
#230Earlier quoted context omitted.
I expect a lot of people will be doing a whole lot of thinking along these lines over the next months. Code review? Some kind of behavioral analysis? IMO the call to system() was kind of sloppy, and a binary capabilities scanner could have potentially identified a path to that.
The real problem was doing expensive math for every connection. If it had relied on a cookie or some simpler-to-compute pre-filter, no one would have been the wiser.
The slowdown is actually in the startup of the backdoor, not when it's actually performing authentication. Note how in the original report even sshd -h (called in the right environment to circumvent countermeasures) is slow.