Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

bsky.app

Post reply on HN
Print view View original

171–180 of 862 posts

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

#171

Post by ffsm8 »

tux3 wrote: post #119
wepple wrote: 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.

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…

> No one wants a Linux antivirus

ClamAV has been around for a very long time at this point.

It's just not installed on servers, usually

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

#172

Post by ajross »

admax88qqq wrote: post #161
ajross wrote: post #148

Earlier quoted context omitted.

It's possible to spawn a sshd as an unprivileged or partially-capabilitized process. Such as sandbox isn't the default deployment, but it's done often enough and would work as designed to prevent privilege elevation above the sshd process.

How can sshd spawn interactive sessions for other users if it's sandboxed?

Plausibly by having set-user-ID capability but not others an attacker might need.

But in the more common case it just doesn't: you have an sshd running on a dedicated port for the sole purpose of running some service or another under a specific sandboxed UID. That's basically the github business model, for example.

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

#173

Post by ezekg »

gouggoug wrote: post #160
dolmen wrote: post #132

Earlier quoted context omitted.

I can't blame anyone who has missed that dot dissimulated at the beginning of the line. https://git.tukaani.org/?p=xz.git;a=commitdiff;h=f9cf4c05edd...

For people like me whose C knowledge is poor, can you explain why this dot is significant? What does it do in actuality?

As far as I can tell, the check is to see if a certain program compiles, and if so, disable something. The dot makes it so that it always fails to compile and thus always disables that something.

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

#174

Post by justinsaccount »

> Apparently the backdoor reverts back to regular operation if the payload is malformed or the signature from the attacker's key doesn't verify.

Does this mean it's possible to send every ssh server on the internet a malformed payload to get it to disable the backdoor if it was vulnerable?

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

#175

Post by Denvercoder9 »

gouggoug wrote: post #160
dolmen wrote: post #132

Earlier quoted context omitted.

I can't blame anyone who has missed that dot dissimulated at the beginning of the line. https://git.tukaani.org/?p=xz.git;a=commitdiff;h=f9cf4c05edd...

For people like me whose C knowledge is poor, can you explain why this dot is significant? What does it do in actuality?

It's part of a test program used for feature detection (of a sandboxing functionality), and causes a syntax error. That in turn causes the test program to fail to compile, which makes the configure script assume that the sandboxing function is unavailable, and disables support for it.

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

#176

Post by Ekaros »

TheBlight wrote: post #40
dralley wrote: post #32

Earlier quoted context omitted.

I don't know that they had a singular target necessarily. Much like Solarwinds, they could take their pick of thousands of targets if this had gone undetected.

I think we can all agree this attacker was sophisticated. But why would a government want to own tons of random Linux machines that have open sshd mappings? You have to expose sshd explicitly in most cloud environments (or on interesting networks worthy of attack.) Besides, the attacker must've known that if this is all over the internet eventually someone is going to notice. I think the attacker had a target in mind…

Government have lot of money and time to spend. So having one more tool in box for that single time you need to access a target where this work is entirely reasonable investment. Would this if it weren't used have been noticed possibly in years? That gives quite a lot of room to find target for times when it is needed.

And you could have multiple projects doing this type of work in parallel.

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

#177

Post by glandium »

sn wrote: post #136
glandium wrote: post #91

Earlier quoted context omitted.

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

I wonder if there is anything else cmake related that should be looked at. Wasn't cmake support originally added to xz to use with Windows and MSVC?

But that's a check for a Linux feature. So the more interesting question would be, what in the Linux world might be building xz-utils with cmake, I guess using ExternalProject_Add or something similar.

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

#178

Post by javajosh »

fragmede wrote: post #66
greyface- wrote: post #58

Earlier quoted context omitted.

Agreed on a moral level, and it's true that describing this as simply "vulnerable code" doesn't capture the clear malicious intent. I'm just struggling to find a specific crime. CFAA requires unauthorized access to occur, but the attacker was authorized to publish changes to xz. Code is speech. It was distributed with a "no warranty" clause in the license.

CFAA covers distribution of malicious software without the owners consent, the Wire Fraud Act covers malware distribution schemes intended to defraud for property, Computer Misuse act in the UK is broad and far reaching like the CFAA, so this likely fall afoul of that. The GDPR protects personal data, so there's possibly a case that could be made that this violates that as well, though that might be a bit of reach.

In which case the defense will claim, correctly, that this malware was never distributed. It was caught. "Attempted malware distribution" may not actually be a crime (but IANAL so I don't know).

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

#179

Post by kbolino »

semiquaver wrote: post #100
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.

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.

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

#180

Post by saltcured »

semiquaver wrote: post #100
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.

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

You could refactor sshd so most network payload processing is delegated to sandboxed sub-processes. Then an RCE there has less capabilities to exploit directly. But, I think you would have to assume an RCE can cause the sub-process to produce wrong answers. So if the answers are authorization decisions, you can transitively turn those wrong answers into RCE in the normal login or remote command execution context.

But, the normal login or remote command execution is at least audited. And it might have other enforcement of which accounts or programs are permitted. A configuration disallowing root could not be bypassed by the sub-process.

You could also decide to run all user logins/commands under some more confined SE-Linux process context. Then, the actual user sessions would be sandboxed compared to the real local root user. Of course, going too far with this may interfere with the desired use cases for SSH.

Post reply on HN