Live data from Hacker News

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

bsky.app

511–520 of 862 posts

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

#511

Earlier quoted context omitted.

That's an easy thing to say after the fact indeed but yes. In fact after such a disastrous backdoor I wouldn't be surprised if OpenSSH moved all code calling external libraries to unprivileged processes to make sure such an attack can never have such a dramatic effect (an auth bypass would still likely be possible, but that's still way better than a root RCE…). At this point “All libraries could be malicious” is a th…

I don't think that's a threat model that OpenSSH should waste too much time on. Ultimately this is malicious code in the build machine compiling a critical system library. That's not reasonable to defend against. Keep in mind that upstream didn't even link to liblzma. Debian patched it to do so. OpenSSH should defend against that too?

It is possible to prevent libraries from patching functions in other libraries; make those VM regions unwritable, don't let anyone make them writable, and adopt PAC or similar hardware protection so the kernel can't overwrite them either.

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

#512
post #371

If the RCE is Russian, it could be used a communication kill-switch on the morning of an attack outside Ukraine, similar to the Viasat hack https://en.m.wikipedia.org/wiki/Viasat_hack

Why does it have to be russian? Could be any country, even USA, China. I don't see why this sort of attack is limited to Russia.

Exactly I don't understand the obsession with Russia

Literally just a country with people like you and me.

"Jia Tan" does not sound Russian

https://boehs.org/node/everything-i-know-about-the-xz-backdo...

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

#513

Earlier quoted context omitted.

Have to admit I've never understood why password auth is considered so much worse than using a cert - surely a decent password (long, random, etc) is for all practical purposes unguessable, and so you're either using a private RSA key that no-one can guess, or a password that no-one can guess, and then what's the difference? With the added inconvenience of having to pass around a certificate if you want to login to t…

One of the biggest differences is that if you're using password auth, and you are tricked into connecting to a malicious server, that server now has your plaintext password and can impersonate you to other servers. If you use a different strong random password for every single server, this attack isn't a problem, but that adds a lot of management hassle compared to using a single private key. (It's also made more dif…

> if you're using password auth, and you are tricked into connecting to a malicious server, that server now has your plaintext password and can impersonate you to other servers.

Why would the password be sent in plaintext instead of, say, sending a hash of the password calculated with a salt that is unique per SSH server? Or something even more cryptographically sound.

In fact, passwords in /etc/shadow already do have random salts, so why aren't these sent over to the SSH client so it can send a proper hash instead of the plaintext password?

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

#514

Earlier quoted context omitted.

sure. what makes you think they aren't?

Why would the FBI investigate the NSA? We have zero idea who the actors involved are.

It's not actually unusual for three-letter US agencies to be at odds with one another.

But one possible reason is if the FBI is convinced that something the NSA is doing is illegal. They may not always be inclined to tolerate that.

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

#515

Earlier quoted context omitted.

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?

Lots. It's basically an extra processor that runs at all times, even when your computer is supposedly "off." Its firmware is bigger than you'd think, like a complete Unix system big. It's frankly terrifying how powerful and opaque it is. It provides a lot around remote management for corporations, lots of "update the BIOS remotely" sort of features, and also a bunch of those stupid copy protection enforcement things. Plus some startup/shutdown stuff like Secure Boot.

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

#516
post #119

Earlier quoted context omitted.

I think behavioral analysis could be promising. There's a lot of weird stuff this code does on startup that any reasonable Debian package on the average install should not be doing in a million years. Games and proprietary software will sometimes ship with DRM protection layers that do insane things in the name of obfuscation, making it hard to distinguish from malware. But (with only a couple exceptions) there's no…

Sorry, I'm unfamiliar with PLT what does stand for?

procedure linkage table

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

#517
post #99

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

Dynamic linking was a mistake and should be eliminated

yep, but how to reverse such a blunder?

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

#518

Earlier quoted context omitted.

My understanding is that we know somehow already what the exploit allows the attacker to do - we just can't reproduce it because we don't have their private key. Technically, we can modify the backdoor and embed our own public key - but there is no way to probe a random server on the internet and check if it's vulnerable (from a scanner perspective). In a certain way it's a good thing - only the creator of the backdo…

It's a NOBUS (Nobody But Us can use it) attack. The choice to use a private key means it's possible that even the person who submitted the tampered code doesn't have the private key, only some other entity controlling them does.

[dead]

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

#519

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…

> There was nothing wrong with "unmaintained" lzma two years ago.

Well, that's not exactly true. The first patch from Jia Tan is a minor documentation fix, and the second is a bugfix which, according to the commit message (by Collin), "breaks the decoder badly". There's a few more patches after that that fix real issues.

Mark Adler's zlib has been around for a lot longer than xz/liblzma, and there's still bugfixes to that, too.

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

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

This was the backdoor we found. We found the backdoor with performance issues. Whats more likely - that this is the only backdoor like this in linux, or that there are more out there and this is the one we happened to find? I really hope someone is out there testing for all of this stuff in linux: - Look for system() calls in compiled binaries and check all of them - Look for uses of IFUNC - specifically when a libra…

All of this was obfuscated. None of this will be detectable with current static analysis techniques.
Post reply on HN