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

281–290 of 862 posts

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

#281

Post by XorNot »

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.

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 we don't actually track data providence like this - no build system does. The most we do is -> . But we don't include the human readable data which explains how that transform happens at enough levels.

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

#282

Post by concordDance »

1oooqooq wrote: post #97
jmward01 wrote: post #39

Where is the law enforcement angle on this? This individual/organization needs to be on the top of every country's most wanted lists.

easy there. calling the cops on the NSA might be treason or something

I would have thought NSA would have hardware/firmware backdoor everywhere and wouldn't need this.

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

#284

Post by cqqxo4zV46cp »

undersuit wrote: post #238
legobmw99 wrote: post #221

Earlier quoted context omitted.

Why would open source models make this scenario you are painting better?

Because in the closed source model the frustrated developer that looked into this SSH slowness submits a ticket for the owner of the malicious code to dismiss.

It’s insane to consider the actual discovery of this to be anything other than a lightning strike. What’s more interesting here is that we can say with near certainty that there are other backdoors like this out there.

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

#285

Post by dboreham »

danparsonson wrote: post #246
tialaramex wrote: post #17

Earlier quoted context omitted.

One completely awful thing some scanners might choose to do is if you're offering RSA auth (which most SSH servers are and indeed the SecSH RFC says this is Mandatory To Implement) then you're "potentially vulnerable" which would encourage people to do password auth instead. Unless we find that this problem has somehow infested a lot of real world systems that seems to me even worse than the time similar "experts" de…

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…

It depends what happens to the password. Typically it's sent as a bearer credential. But there are auth schemes (not widely used these days) where the password isn't sent over the wire.

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

#287

Post by cqqxo4zV46cp »

pas wrote: post #219
martinohansen wrote: post #207

Imagine a future where state actors have hundreds of AI agents fixing bugs, gaining reputation while they slowly introduce backdoors. I really hope open source models succeed.

... if we want security it needs trust anyway. it doesn't matter if it's amazing Code GPT or Chad NSA, the PR needs to be reviewed by someone we trust. it's the trust that's the problem. web of trust purists were right just ahead of the time.

That just…doesn’t make any sense.

Everyone starts from zero and works their way up.

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

#288

Post by XorNot »

raggi wrote: post #154
djao wrote: post #140

Earlier quoted context omitted.

Maybe they didn't have time to test? They could have been scrambling to make it into timed releases such as Ubuntu 24.04 or Fedora 40.

There is one possible time pressure involved, which is that libsystemd dropped the liblzma dependency

Absolutely no intelligence agency would look at a successful compromise where they have a highly positioned agent in an organization like this, and burn them trying to rush an under-developed exploit in that would then become not useful almost immediately (because the liblzma dependency would be dropped next distro upgrade cycle).

If you had a human-asset with decision making authority and trust in place, then as funded organization with regular working hours, you'd simply can the project and start prototyping new potential uses.

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

#290

Post by swid »

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?

Replayability means something different in this context. First, we do know the backdoor will pass the payload to system, so in general it is like an attacker has access to bash, presumably as root since it is sshd.

Replayability means, if someone were to catch a payload in action which did use the exploit, you can’t resend the attacker’s data and have it work. It might contain something like a date or other data specific only to the context it came from. This makes a recorded attack less helpful for developing a test… since you can’t replay it.

Post reply on HN