Live data from Hacker News

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

bsky.app

41–50 of 862 posts

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

#42

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

Well, the definition of "improve" depends on one's goals.

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

#43

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?

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

#45

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…

I mostly agree with you, but I think your argument is wrong. Last month I found a tiny bug in Unix's fgrep program(the bug has no risk). The program implements Aho Corasick algorithm, which hasn't changed much over decades. However, at least when the code was released to 4.4BSD, the bug still existed. It is not much a concern as nowadays most fgrep progroms are just an alias of grep. They do not use the old Unix code anymore. The old Unix code, and much part of FreeBSD, really couldn't meet today's security standard.For example, many text processing programs are vulnerable to DoS attacks when processing well-crafted input strings. I agree with you that in many cases we really don't need to touch the old code. However, it is not just because the algorithm didn't change.

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

#46

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…

[deleted]

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

#48

If that's true, then I am 100% certain that this backdoor is from a nation state-level actor.

I already felt like this was way too sophisticated for a random cybercriminal. It's not like making up fake internet identities is very difficult, but someone has pretended to be a good-faith contributor for ages, in a surprisingly long-term operation. You need some funding and a good reason to pull off something like that. This could also be a ransomware group hoping to break into huge numbers of servers, though. Ra…

Those guys are estimated to have made $1 billion last year - have to think that buys some developer talent.

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

#50

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.

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