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

531–540 of 862 posts

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

#531

Post by Deathcrow »

formerly_proven wrote: post #138
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 this would’ve been difficult to catch because the patching of sshd happens during linking, when it’s permissible, and if this is correct then it’s not a master key backdoor, so there is no regular login audit trail. And sshd would of course be allowed to start other processes. A very tight SELinux policy could catch sshd executing something that ain’t a shell but hardening to that degree would be extremely ra…

>A very tight SELinux policy could catch sshd executing something that ain’t a shell but hardening to that degree would be extremely rare I assume.

Huh, ssh executes things that aren't shells all the time during normal operation. No? i.e. 'ssh myserver.lan cat /etc/fstab'

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

#532

Post by AnonHP »

SV_BubbleTime wrote: post #373
tialaramex wrote: post #355

Earlier quoted context omitted.

Private key. In cryptography we distinguish keys which are symmetric (needed by both parties and unavailable to everyone else) as "Secret" keys, with the pair of keys used in public key cryptography identified as the Private key (typically known only to one person/ system/ whatever) and Public key (known to anybody who cares) Thus, in most of today's systems today your password is a secret . You know your password an…

> You know your password and so does the system authenticating you. Nitpick, but no it shouldn’t. The HASH of your password is recorded. You never submit your password, you submit that hash and they compare it. The difference is that there is no two passwords that collide; but there are hashes that may. And that two equal passwords from two equal users are not necessarily accessible to someone with the hash list beca…

> Nitpick, but no it shouldn’t. The HASH of your password is recorded. You never submit your password, you submit that hash and they compare it.

Nitpick, but the password is submitted as-is by most client applications, and the server hashes the submitted password and compares it with the hash it has (of course, with salting).

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

#533

Post by pilgrim0 »

tambourine_man wrote: post #425

I’d like to know what we mortals – those that run Ubuntu LTS on VMs, for instance — need to do, if anything.

I would, by routine, advise that publicly available boxes are configured to accept connections only from whitelisted sources, doing that at the lowest possible level on the stack. That’s usually how secure environments such as those used in PCI compliant topologies are specified.

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

#534

Post by Deathcrow »

cjbprime wrote: post #497
zeven7 wrote: post #462

Earlier quoted context omitted.

> The problem with xz wasn't a small community; it was no community. A single malicious actor got control of the project, and there was little oversight from anyone else. So because of this a lot of other highly used software was importing and depending on unreviewed code. It's scary to think how common this is. The attack surface seems unmanageable. There need to be tighter policies around what dependencies are incl…

Even if you mandated two code reviewers per merge, the attacker can just have three fake personas backed by the same single human and use them to author and approve malware.

Also, in a more optimistic scenario without sockpuppets, it's unlikely that malicious and underhanded contributions will be caught by anyone that isn't a security researcher.

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

#535

Post by sureglymop »

computerfriend wrote: post #488
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…

I sometimes ask this as an interview question. Hardly anybody knows the answer.

So don't you want to enlighten us with the answer?

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

#536

Post by danparsonson »

someplaceguy wrote: post #513
teraflop wrote: post #278

Earlier quoted context omitted.

One of the biggest differences is that if you're using password auth, and you are tricked into connecting to a malicious server, that server now has your plaintext password and can impersonate you to other servers. If you use a different strong random password for every single server, this attack isn't a problem, but that adds a lot of management hassle compared to using a single private key. (It's also made more dif…

> if you're using password auth, and you are tricked into connecting to a malicious server, that server now has your plaintext password and can impersonate you to other servers. Why would the password be sent in plaintext instead of, say, sending a hash of the password calculated with a salt that is unique per SSH server? Or something even more cryptographically sound. In fact, passwords in /etc/shadow already do hav…

If the hash permits a login then having a hash is essentially equivalent to having a password. The malicious user wouldn't be able to use it to sudo but they could deploy some other privilege escalation once logged in.

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

#537

Post by sureglymop »

4death4 wrote: post #453
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.

Imagine a world where a single OSS maintainer can do the work of 100 of today’s engineers thanks to AI. In the world you describe, it seems likely that contributors would decrease as individual productivity increases.

Wouldn't everything produced by an AI explicitly have to be checked/reviewed by a human? If not, then the attack vector just shifts to the AI model and that's where the backdoor is placed. Sure, one may be 50 times more efficient at maintaining such packages but the problem of verifiably secure systems actually gets worse not better.

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

#538

Post by danparsonson »

imrehg wrote: post #341
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…

On that last point, I wouldn't pass around the certificate to log in from multiple sources, rather each source would have its own certificate. That is easy & cheap to do (especially with ed25519 certs).

Ah right, that's useful, thanks. Presumably if you need to login from an untrusted source (e.g. in an emergency), then you're out of luck in that case? Do you maybe keep an emergency access cert stashed somewhere?

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

#539

Post by webmaven »

rcxdude wrote: post #336
everybackdoor wrote: post #292

Earlier quoted context omitted.

[flagged]

This is full conspiracy mode thinking.

Yes, well, there actually was a conspiracy here, wasn't there? The only question is how extensive it was in time and space.

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

#540

Post by Deathcrow »

ghostpepper wrote: post #189
skywhopper wrote: post #128

Earlier quoted context omitted.

From what I’ve read I think the attack vector is: 1. sshd starts and loads the libsystemd library which loads the XZ library which contains the hack 2. The XZ library injects its own versions of functions in openssl that verify RSA signatures 3. When someone logs into SSH and presents a signed SSH certificate as authentication, those hacked functions are called 4. The certificate, in turn, can contain arbitrary data…

> beyond the (presumably failed) login attempt There is some evidence it's scrubbing logs so we might not even have that.

Is there really a failed login attempts? If it never calls the real functions of ssh in case of their own cert+payload why would sshd log anything or even register a login attempt? Or does the backdoor function hook in after sshd already logged stuff?
Post reply on HN