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

661–670 of 862 posts

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

#661

Post by cmcaleer »

junon wrote: post #275
tootie wrote: post #255

Earlier quoted context omitted.

Mind boggling. How do you even decide what to do with privileges on a billion computers?

There's a reasonably high chance this was to target a specific machine, or perhaps a specific organization's set of machines. After that it could probably be sold off once whatever they were using it for was finished. I doubt we'll ever know the intention unless the ABC's throw us a bone and tell us the results of their investigation (assuming they're not the ones behind it).

Classic example of this being Stuxnet, a worm that exploited four(!) different 0-days and infected hundreds of thousands of computers with the ultimate goal of destroying centrifuges associated with Iran’s nuclear program.

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

#662

Post by Muromec »

numpad0 wrote: post #558
Muromec wrote: post #494

Earlier quoted context omitted.

Overcomplicated design, sloppy opsec and Eastern European time zone altogether sound more like an attempt to snatch some bitcoins by a small group of people in places.

I wonder what had happened in Eastern Europe ~2 years ago...

The obvious, but not yet pointed out part here -- not everything we call "EE" here is actually using EET/EEST.

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

#663

Post by phire »

sunshine_reggae wrote: post #643
lll-o-lll wrote: post #395

Earlier quoted context omitted.

> That said, if you're not using it, it defeats the purpose. Not if this was injected by a state actor. My experience with other examples of state actor interference in critical infrastructure, is that the exploit is not used. It’s there as a capability to be leveraged only in the context of military action.

And that leads to the question: Why do non-friendly state actors (apparently) not detect and eliminate exploits like this one? Supposedly, they should have the same kind of budgets for code review (or even more, if we combine all budgets of all non-friendly state actors, given the fact that we are talking about open-source code).

How to you know they don't?

When a state actor says "We found this exploit", people will get paranoid and wondering if the fix is actually an exploit.

Not saying it happened in this case, but it's really easy for a state actor to hide an extensive audit behind some parallel construction. Just create a cover story pretending to be a random user who randomly noticed ssh logins being slow, and use that story to point maintainers to the problem, without triggering anyone's paranoia, or giving other state actors evidence of your auditing capabilities.

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

#664

Post by usrusr »

rmi_ wrote: post #274
plg94 wrote: post #129

Earlier quoted context omitted.

I don't think we know what exactly this does, yet. I can only answer one of those questions, as far as I understand the "unreplayable" part is refering to this: > Apparently the backdoor reverts back to regular operation if the payload is malformed or *the signature from the attacker's key doesn't verify*. emphasis mine, note the "signature of the attacker's key". So unless that key is leaked, or someone breaks the R…

> So unless that key is leaked But, just for replayability, we could "patch" the exploit with a known key and see what it does, don't we?

What could be done, I think, is patch the exploit into logging the payload (and perhaps some network state?) instead of executing it to be able to analyse it. Analyse it, in the unlikely case that the owner of the key would still try their luck using it after discovery, on a patched system.

What it does: it's full RCE, remote code execution, it does whatever the attacker decides to upload. No mystery there.

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

#665

Post by Muromec »

tw04 wrote: post #571
Muromec wrote: post #483

Earlier quoted context omitted.

The whole Chinese name and UTC+8 were a cover, as the person apparently was from EET

While it ultimately doesn’t matter if it was Russia or China beyond potential political fallout. Do you have a link to the proof pointing towards EET?

There was a link in this thread pointing to commit times analysis and it kinda checks out. Adding some cultural and outside world context, I can guess which alphabet this three-four-six-letter agency uses to spell it's name at least.

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

#666

Post by sensanaty »

benreesman wrote: post #469
tigerlily wrote: post #370

As a de facto maintainer of an obscure open source game, I see devs come and go. I just merge all the worthwhile contributions. Some collaborators go pretty deep with their features, with a variety of coding styles, in a mishmash of C and C++. I'm not always across the implementation details, but in the back of my mind I'm thinking, man, anyone could just code up some real nasty backdoor and the project would be scre…

It never ceases to amaze me how great of lengths companies go to round securing the perimeter of the network but then have engineering staffs that just routinely brew install casks or vi/emacs/vscode/etc extensions. Rust is arguably the programming language and/or community with the most secure set of defaults that are fairly impossible to get out of, but even at “you can’t play games with pointers” levels of securit…

I actually avoided installing Rust originally because I thought that install page was hijacked by an attacker or something.

Most languages don't have the prettiest install flows, but a random `curl | sh` is just lunacy if you're at all security conscious

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

#667

Post by dotancohen »

ajross wrote: post #172
admax88qqq wrote: post #161

Earlier quoted context omitted.

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.

I need full filesystem access, VIM, ls, cd, grep, awk, df, du at the very least. Sometimes perl, find, ncdu, and other utilities are necessary as well. Are you suggesting that each tool have its own SSH process wrapping it?

Maybe write a shell to coordinate between them? It should support piping and output redirection, please.

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

#668

Post by paulmd »

XorNot wrote: post #281
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.

If you think about it this is a data-providence problem though. The exploit was hidden in "test" code which gets included in release code by compiler flags. Now, if there was a proper chain of accountability for data, then this wouldn't have been possible to hide the way it is - any amount of pre-processing resulting in the release tarball including derived products of "test" files would be suspicious. The problem is…

You don’t need to go to that extent even - simply properly segregating test resources from dist resources would have prevented this, and that’s something Java has been doing for 20 years.

It’s not sufficient against a determined attacker, but it does demonstrate just how unserious the C world is about their build engineering.

I literally can’t think of a single time in 15 years of work that I’ve ever seen a reason for a dist build to need test resources. That’s at best a bug - if it’s a dist resource it goes in the dist resources, not test. And if the tooling doesn’t do a good job of making that mistake difficult… it’s bad tooling.

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

#669

Post by Cloudef »

radiospiel wrote: post #647
kbenson wrote: post #541

Earlier quoted context omitted.

That this was dynamically linked is the least interesting thing about it IMO. It was a long term I filtration where they got legitimate commit access to a well used library. If xz was statically linked in some way, or just used as an executa Le to compress something (like the kernel), the same problems exist and no dynamic linking would need to be involved.

> If xz was statically linked in some way, or just used as an executa Le to compress something (like the kernel), the same problems exist and no dynamic linking would need to be involved. even more so: all binaries dynamically linking xz can be updated by installing a fixed library version. For statically linked binaries: not so much, each individual binary would have to be relinked, good luck with that.

> For statically linked binaries: not so much, each individual binary would have to be relinked, good luck with that.

Is essentially what all distros with sane build systems does.

Post reply on HN