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."

#91

Post by glandium » Sat, Mar 30, 2024, 9:21 PM UTC

onedognight wrote: post #38

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.

> With the right sandboxing techniques, SELinux and mitigations could prevent the attacker from doing anything with root permissions. Please review this commit[0] where the sandbox detection was “improved”. [0] https://git.tukaani.org/?p=xz.git;a=commitdiff;h=328c52da8a2...

Oh, that one is interesting, because it only breaks it in cmake.

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

#92

Post by sneak » Sat, Mar 30, 2024, 9:21 PM UTC

ceejayoz wrote: post #86

sneak wrote: post #80

Earlier quoted context omitted.

The criminal conspiracy laws don’t apply to the organizations that write this kind of code, just like murder laws don’t.

Sure they do. Getting the perpetrator into your jurisdiction is the tough part. Putin is, for example, unlikely to go anywhere willing to execute an ICC arrest warrant.

Nah, the CIA assassinates people in MLAT zones all the time. The laws that apply to you and I don’t apply to the privileged operators of the state’s prerogatives.

We don’t even know that this specific backdoor wasn’t the NSA or CIA. Assuming it was a foreign intelligence service because the fake name was asian-sounding is a bit silly. The people who wrote this code might be sitting in Virginia or Maryland already.

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

#93

Post by mik1998 » Sat, Mar 30, 2024, 9:24 PM UTC

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.

[flagged]

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

#94

Post by consumer451 » Sat, Mar 30, 2024, 9:27 PM UTC

polio wrote: post #82

StefanBatory wrote: post #50

Earlier quoted context omitted.

Even if it's not his fault the maintainer at this point won't be trusted at all. I feel for him, I think even finding a job at this moment for him would be impossible. Why would you hire someone that could be suspected for that?

This could've happened to anybody, frankly. The attacker was advanced and persistent. I cannot help but feel sympathetic for the original maintainer here.

From TFA's profile:

https://bsky.app/profile/filippo.abyssdomain.expert/post/3ko...

This is a profound realization, isn't it? How much more paranoid should/will maintainers be going forward?

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

#95

Post by sega_sai » Sat, Mar 30, 2024, 9:31 PM UTC

One have question on this is, if the backdoor would not been discovered due to performance issue (which was as I understood it purely an oversight/fixable deficiency in the code), what are the chances of discovering this backdoor later, or are there tools that would have picked it up? Those questions are IMO relevant to understand if this kind of backdoor is the first one of the kind, or the first one that was uncovered.

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

#96

Post by moomoo11 » Sat, Mar 30, 2024, 9:31 PM UTC

joshcryer wrote: post #21

tempodox wrote: post #18

Earlier quoted context omitted.

Apparently it’s not in the original repo, but in a build script in a distribution tar.

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?

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

#97

Post by 1oooqooq » Sat, Mar 30, 2024, 9:33 PM UTC

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

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

#98

Post by rdtsc » Sat, Mar 30, 2024, 9:34 PM UTC

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) Is XZ for Java still maintained?

> (Lasse) I haven't lost interest but my ability to care has been fairly limited mostly due to ...

> (Lasse) Recently I've worked off-list a bit with Jia Tan on XZ Utils and perhaps he will have a bigger role in the future, we'll see. It's also good to keep in mind that this is an unpaid hobby project

With a few years worth of work by a team of 2-3 people: one writes and understand the code, one communicates, a few others pretend to be random users submitting ifunc patches, etc., you can end up controlling the project and signing releases.

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

#99

Post by wepple » Sat, Mar 30, 2024, 9:35 PM UTC

sega_sai wrote: post #95

One have question on this is, if the backdoor would not been discovered due to performance issue (which was as I understood it purely an oversight/fixable deficiency in the code), what are the chances of discovering this backdoor later, or are there tools that would have picked it up? Those questions are IMO relevant to understand if this kind of backdoor is the first one of the kind, or the first one that was uncove…

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.

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

#100

Post by semiquaver » Sat, Mar 30, 2024, 9:36 PM UTC

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.

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