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

301–310 of 862 posts

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

#301

Post by duskwuff »

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…

> Have to admit I've never understood why password auth is considered so much worse than using a cert

Password auth involves sending your credentials to the server. They're encrypted, but not irreversibly; the server needs your plaintext username and password to validate them, and it can, in principle, record them to be reused elsewhere.

Public key and certificate-based authentication only pass your username and a signature to the server. Even if you don't trust the server you're logging into, it can't do anything to compromise other servers that key has access to.

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

#302

Post by cqqxo4zV46cp »

qudat wrote: post #85
codetrotter wrote: post #29

Earlier quoted context omitted.

It’s pretty funny how a bunch of people come piling reaction emojis onto the comments in the PR, after it has all become publicly known. I’m like.. bro, adding reaction emojis after the fact as if that makes any sort of difference to anything.

Feels almost like tampering with evidence at a crime scene

That’s absurd. Elaborate.

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

#303

Post by cryptonector »

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…

> But I think everyone would benefit from throwing all the behavioral analysis we can come up with at new Debian package uploads.

Why "new uploads" and not also "all existing"?

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

#304

Post by semiquaver »

kbolino wrote: post #240
sweetjuly wrote: post #228

Earlier quoted context omitted.

>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 This is sort of overlooking the problem. While true, the processes spawned by sshd do need to be able to do all these things and so even if you did sandbox it, preserving functionality would all but guarantee an escape is trivial (...just spawn bash?).

SELinux context is passed down to child processes. If sshd is running as confined root (system_u:system_r:sshd_t or similar), then the bash spawned by RCE will be too. Even if sshd is allowed to masquerade as an unconfined non-root user, that user will (regardless of SELinux) be unable to read or write /dev/kmem, ignore standard file permissions, etc.

I’ll admit to not being an expert in SELinux, but it seems like an impossibly leaky proposition. Root can modify systemd startup files, so just do that in a malicious way and reboot the system. that context won’t be propagated. And if you somehow prohibit root from doing that by SELinux policy then you end up with a system that can’t actually be administered.

[edit: sibling sweetjuly said it better than I could. I doubt that this much more than a fig leaf on any real world system given what sshd is required to have to do.]

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

#305

Post by solardev »

dboreham wrote: post #285
danparsonson wrote: post #246

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…

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.

Isn't it pretty standard practice to salt and hash the password client-side before sending it over the wire?

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

#306

Post by matrix_overload »

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.

Not necessarily. A frustrated developer posts about it, it catches attention of someone who knows how to use Ghidra et al, and it gets dug out quite fast.

Except, with closed-source software maintained by a for-profit company, suck cockup would mean a huge reputational hit, with billions of dollars of lost market cap. So, there are very high incentives for companies to vet their devs, have proper code reviews, etc.

But with open-source, anyone can be a contributor, everyone is a friend, and nobody is reliably real-world-identifiable. So, carrying out such attacks is easier by orders magnitude.

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

#307

Post by denysvitali »

justinsaccount wrote: post #174

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

It just reverts it for the specific connection - most likely to not raise suspicions on the fact that SSH doesn't accept RSA keys anymore

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

#308

Post by nurple »

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 think one interesting corollary here is how the Ken Thompson attack was discovered at PWB[0] because it had a memory performance bug[1].

  [0] https://en.wikipedia.org/wiki/PWB/UNIX
  [1] https://news.ycombinator.com/item?id=38020792

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

#309

Post by [deleted] »

legobmw99 wrote: post #268
undersuit wrote: post #238

Earlier quoted context omitted.

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.

This seems completely unrelated to the grandparent comment’s mention of open source LLMs

[deleted]

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

#310

Post by matrix_overload »

londons_explore wrote: post #250
quatrefoil wrote: post #135

Earlier quoted context omitted.

If the exploit wasn't baing used, the odds would would be pretty low. They picked the right place to bury it (i.e., effectively outside the codebase, where no auditor ever looks). That said, if you're not using it, it defeats the purpose. And the more you're using it, the higher the likelihood you will be detected down the line. Compare to Solarwinds.

I suspect I could have used this exact attack against 10,000 random SSH servers spread all over the world, and not be detected. Most people don't log TCP connections, and those that do don't go through their logs looking for odd certificates in ssh connections. And no common logging at the ssh/pam level would have picked this up. Your only chance is some sysadmin who has put 'tripwires' on certain syscalls like syste…

With sufficient data points, you can do A/B and see that all affected systems run a specific version of Linux distro, and eventually track it down to a particular package.
Post reply on HN