XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable." • Hacker News Board

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

#121

Post by asveikau » Sat, Mar 30, 2024, 9:57 PM UTC

snnn wrote: post #115

asveikau wrote: post #71

Earlier quoted context omitted.

> the 32-bit to 64-bit transition Lzma is from 2010. Amd64 became mainstream in the mid 2000s. > removal of pre-C89 support Ibid. Also, at the library API level, c89 compatible code is still pretty familiar to c99 and later. > new architectures like RISC-V Shouldn't matter for portable C code? > the increasing amount of cores and a slowdown in the increase of per-core speed, Iirc parallelism was already a focus of th…

Actually, the new architectures are a big source of concerns. As a maintainer of a large open source project, I often received pull requests for CPU architectures that I never had a chance to touch. Therefore I cannot build the code, cannot run the tests, and do not understand most of the code. C/C++ themselves are portable, but libs like xz needs to beat the other competitors on performance, which means you may need…

I am a former MS employee, I used to read the compatibility patches when I was bored at the office.

Anyway, liblzma does not "need" to outperform any "competition". If someone wants to work on some performance optimization, it's completely fair to fork. Look at how many performance oriented forks there are of libjpeg. The vanilla libjpeg still works.

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

#122

Post by colinsane » Sat, Mar 30, 2024, 9:58 PM UTC

chris_wot wrote: post #116

rdtsc wrote: post #105

Earlier quoted context omitted.

At least for some comic relief I'd like to imagine Jia's boss slapping him and saying something like "you idiot, we worked on this for so many years and you couldn't have checked for any perf issues?" But seriously, we could have found ourselves with this in all stable repos: RHEL, Debian, Ubuntu, IoT devices 5 years from now and it would have been a much larger shit show.

Surely this is something the FBI should be involved with? Or some authority?

sure. what makes you think they aren't?

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

#123

Post by swid » Sat, Mar 30, 2024, 9:59 PM UTC

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…

You can imagine a door that opens if you knock on it just right. For anyone without the secret knock, it appears and functions as a wall. Without the secret knock, there might not even be a way to prove it opens at all.

This is sort of the situation here. xz tries to decode some data before it does anything shady; since it is asymmetric; it can do the decryption without providing the secret encryption key (it has the public counterpart).

The exploit code may never be available, because it is not practical to find the secret key, and it doesn't do anything obviously different if the payload doesn't decrypt successfully. The only way to produce the exploit code would be if the secret key is found somehow; and the only real way for that to happen would be for the people who developed the backdoor to leak it.

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

#124

Post by thinkingemote » Sat, Mar 30, 2024, 9:59 PM UTC

nocoiner wrote: post #28

dc-programmer wrote: post #20

Earlier quoted context omitted.

I agree, but the social engineering parts do feel particularly cruel

I felt really bad for the original maintainer getting dog-piled by people who berated him for not doing his (unpaid) job and basically just bring shame and discredit to himself and the community. Definitely cruel. Though… do we know that the maintainer at that point was the same individual as the one who started the project? Goes deep, man.

Its possible the adversary was behind or at least encouraged the dog piling who berated him. Probably a normal basic tactic from a funded evil team playbook.

Might be worth reviewing those who berated him to see if they resolve to real people, to see how deep this operation goes.

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

#125

Post by dolmen » Sat, Mar 30, 2024, 9:59 PM UTC

git.tukaani.org runs sshd. If that sshd was upgraded with the xz backdoor, we cannot exclude that the host was compromised as it could be have been a obvious target for the backdoor author.

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

#126

Post by almostnormal » Sat, Mar 30, 2024, 10:00 PM UTC

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.

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

#127

Post by snnn » Sat, Mar 30, 2024, 10:00 PM UTC

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…

That's the most interesting part. No, we don't know it yet. The backdoor is so sophisticated that none of us can fully understand it. It is not a “usual” security bug.

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

#128

Post by skywhopper » Sat, Mar 30, 2024, 10:07 PM UTC

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…

From what I’ve read I think the attack vector is:

1. sshd starts and loads the libsystemd library which loads the XZ library which contains the hack

2. The XZ library injects its own versions of functions in openssl that verify RSA signatures

3. When someone logs into SSH and presents a signed SSH certificate as authentication, those hacked functions are called

4. The certificate, in turn, can contain arbitrary data that in a normal login process would include assertions about username or role that would be used to determine if the certificate is valid for use logging in as the particular user. But if the hacked functions detect that the certificate was signed by a specific attacker key, they take some subfield of the certificate and execute it as a command on the system in the sshd context (ie, as the root user).

Unfortunately, we don’t know the attacker’s signing key, just the public key the hacked code uses to validate it. But basically this would give the attacker a way to run any command as root on any compromised system without leaving much of a trace, beyond the (presumably failed) login attempt, which any system on the internet will be getting a lot of anyway.

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

#129

Post by plg94 » Sat, Mar 30, 2024, 10:08 PM UTC

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 RSA algorithm (in which case we have far bigger problems), it's impossible for someone else (researcher or third-party) to exploit this backdoor.

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

#130

Post by CSMastermind » Sat, Mar 30, 2024, 10:08 PM UTC

moomoo11 wrote: post #96

joshcryer wrote: post #21

Earlier quoted context omitted.

They also used social engineering to disable fuzzing which would have caught the discrepancy: https://github.com/google/oss-fuzz/pull/10667

Is the person Jia who did this PR a malicious actor?

The person who submitted the PR, JiaT75, is.

The person who approved and merged it is not.