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

141–150 of 862 posts

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

#141

Post by raggi »

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…

Except had we been doing that they would have put guards in place to detect it - as they already had guards to avoid the code path when a debugger is attached, to avoid building the payload in when it's not one of the target systems, and so on. Their evasion was fairly extensive, so we'd need many novel dynamic systems to stand a chance, and we'd have to guard those systems extremely tightly - the author got patches into oss-fuzz as well to "squash false positives". All in all, adding more arms to the arms race does raise the bar, but the bar they surpassed already demonstrated tenacity, long term thinking, and significant defense and detection evasion efforts.

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

#142

Post by formerly_proven »

Denvercoder9 wrote: post #56
onedognight wrote: post #38

Earlier quoted context omitted.

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

That one's a separate attack vector, which is seemingly unused in the sshd attack. It only disables sandboxing of the xzdec(2) utility, which is not used in the sshd attack.

Which strongly suggests that they planned and/or executed more backdoors via Jia Tan’s access.

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

#143

Post by x0x0 »

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

[flagged]

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

#144

Post by jnwatson »

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

The real problem was doing expensive math for every connection. If it had relied on a cookie or some simpler-to-compute pre-filter, no one would have been the wiser.

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

#145

Post by drowsspa »

hnarn wrote: post #110
greyface- wrote: post #43

Earlier quoted context omitted.

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?

What is constantly overlooked here on HN is that in legal terms, one of the most important things is intent . Commenters on HN always approach legal issues from a technical perspective but that is simply not how the judicial system works. Whether something is “technically X” or not is irrelevant, laws are usually written with the purpose of catching people based on their intent (malicious hacking), not merely on the…

Yeah, it bothers me so much. They really seem to think that "law is code".

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

#146

Post by Muromec »

dolmen wrote: post #132
onedognight wrote: post #38

Earlier quoted context omitted.

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

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

I specifically opened this diff to search for a sneaky dot, knowing it’s there, and wasn’t able to find it until I checked the revert patch

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

#147

Post by raggi »

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

the call to system is obfuscated, static analysis wouldn't see it

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

#148

Post by ajross »

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.

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.

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

#149

Post by snnn »

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…

> to try to overwrite symbols in other modules, to add LD audit hooks on startup, to try to resolve things manually by walking ELF structures

I want to name one thing: when Windows failed to load a DLL because a dependency was missing, it doesn't tell you what was missed. To get the information, you have to interact with the DLL loader with low level Windows APIs. In some circumstances Linux apps may also have the need. Like for printing a user friendly error message or recovery from a non-fatal error. For example, the patchelf tool that is used for building portable python packages.

> No one wants a Linux antivirus

It is not true. Actually these software are very popular in enterprise settings.

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

#150

Post by raggi »

x0x0 wrote: post #143
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.

[flagged]

Think whatever you shall about systemd of course, but please stop with the blind belief mud slinging:

  - systemd didn't create the patch to include libsystemd, distros did
  - current systemd versions already remove liblzma from their dependencies, the affected distros are behind on systemd updates though
  - you can implement notify in standalone code in about the same effort as it takes to use the dependency, there wasn't really a good reason for distro's to be adding this dependency to such a critical binary. systemd documents the protocol independently to make this easy. distros having sketchy patches to sshd has a long history, remember the debian weak key fiasco?
Post reply on HN