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

711–720 of 862 posts

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

#711

Post by tialaramex »

kortilla wrote: post #572
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…

Private keys are also “secrets” here in the security world. “Vault secures, stores, and tightly controls access to tokens, passwords, certificates, API keys, and other secrets in modern computing” Your distinction is not shared by the industry so it’s not something helpful to correct people on.

I don't think I can take seriously in this context a quote in which certificates (a type of public document) are also designated "secrets".

Like, sure, they're probably thinking of PKCS#12 files which actually have the private key inside them, not just the certificate, but when they are this sloppy of course they're going to use the wrong words.

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

#712

Post by matheusmoreira »

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

If a government is competent enough to detect this, they're competent enough to add it to their very own cyberweapon stockpile.

They wouldn't be able to do that for this particular exploit since it requires successfully decrypting data encrypted by the attacker's secret key. A zero day caused by an accidental bug though? There's no reason for them to eliminate the threat by disclosing it. They can patch their own systems and add yet another exploit to their hoard.

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

#713

Post by kbolino »

alrs wrote: post #528
CanaryLayout wrote: post #456

Earlier quoted context omitted.

even easier is to STOP HOSTING SSHD ON IPV4 ON CLEARNET at minimum, ipv6 only if you absolutely must do it (it absolutely cuts the scans way down) better is to only host it on vpn even better is to only activate it with a portknocker, over vpn even better-better is to set up a private ipv6 peer-to-peer cloud and socat/relay to the private ipv6 network (yggdrasil comes to mind, but there's other solutions to darknet)…

Who cares about scans? Who cares if a scan comes in 4 or 6?

Forget IPv6, just moving SSH off of port 22 stops the vast majority of drive-by attacks against sshd on the open Internet.

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

#714

Post by jvans »

skywhopper wrote: post #128
chatmasta wrote: post #107

Can someone explain succinctly what the backdoor does ? Do we even know yet? The backdoor itself is not a payload, right? Does it need a malicious archive to exploit it? Or does it hook into the sshd process to listen for malicious packets from a remote attacker? The OP makes it sound like an attacker can send a malicious payload in the pre-auth phase of an SSH session - but why does he say that an exploit might neve…

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…

So is the implication here that any system that allows SSH and contains this malicious code is vulnerable?

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

#715

Post by treasy »

kbolino wrote: post #710
kimixa wrote: post #613

Earlier quoted context omitted.

Really what they're proposing here is a non-modifiable system, where the root is read-only and no user can modify anything important. Which is nice and all, but that implies a "parent" system that creates and deploys those systems. Which people likely want remote access to.. Probably by sshd...

You don't have to have an immutable system. You can limit the exposure of the system from RCE in sshd with SELinux without preventing legitimate users from administering the system. Granted that SELinux is overly complicated and has some questionable design decisions from a usability standpoint but it's not as limited or inflexible as many seem to think. It really can stop a system service running as "root" from doin…

SELinux is overly complicated, but it’s not hard to at least grasp the basics

The amount of people confusing DAC and MAC is concerning. You’ve done an excellent job explaining the topic.

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

#716

Post by versteegen »

dvdkon wrote: post #587
CanaryLayout wrote: post #456

Earlier quoted context omitted.

even easier is to STOP HOSTING SSHD ON IPV4 ON CLEARNET at minimum, ipv6 only if you absolutely must do it (it absolutely cuts the scans way down) better is to only host it on vpn even better is to only activate it with a portknocker, over vpn even better-better is to set up a private ipv6 peer-to-peer cloud and socat/relay to the private ipv6 network (yggdrasil comes to mind, but there's other solutions to darknet)…

How about making ssh as secure as (or more secure than) the VPN you'd put it behind? Considering the amount of vulnerabilities in corporate VPNs, I'd even put my money on OpenSSH today. It's not like this is SSH's fault anyway, a supply chain attack could just as well backdoor some Fortinet appliance.

Defence in depth. Which of your layers is "more secure" isn't important if none are "perfectly secure", so having an extra (independent) layer such as a VPN is a very good idea.

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

#717

Post by broadsidepicnic »

juliusdavies wrote: post #632
broadsidepicnic wrote: post #630

Earlier quoted context omitted.

From what?

Litigation including criminal prosecution

Uh what would be his charge? I cannot fathom how and based on what he would be charged. Maybe this is an american thing, but he's not an US citizen to start with

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

#718

Post by matheusmoreira »

chatmasta wrote: post #107

Can someone explain succinctly what the backdoor does ? Do we even know yet? The backdoor itself is not a payload, right? Does it need a malicious archive to exploit it? Or does it hook into the sshd process to listen for malicious packets from a remote attacker? The OP makes it sound like an attacker can send a malicious payload in the pre-auth phase of an SSH session - but why does he say that an exploit might neve…

Attacker wants to be able to send an especially crafted public key to their target's server's sshd. That crafted key is totally bogus input, a normal sshd would just probably reject it as invalid. The bits embedded into the key are actually malicious code, encrypted/signed with the attacker's secret key.

In order to achieve their objective, they engineered a backdoor into sshd that hooks into the authentication functions which handle those keys. Whenever someone sends a key, it tries to decrypt it with the attacker's keys. If it fails, proceed as usual, it's not a payload. If it successfully decrypts, it's time for the sleeper agent to wake up and pipe that payload into a brand new process running as root.

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

#719

Post by junon »

concordDance wrote: post #691
rubymamis wrote: post #674

It baffles me how such an important package that so many Linux servers use every day is unmaintained by the original author due to insufficient funds. Something gotta change in OSS. I think one solution could be in licenses that force companies/business of certain sizes to pay maintenance fees. One idea from the top of my head.

> It baffles me how such an important package that so many Linux servers use every day is unmaintained by the original author due to insufficient funds. Is it actually insufficient funds or is it burnout?

In the case of XZ it was more akin to burnout based on the literature around the time Jia Tan was instated.

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

#720

Post by junon »

shp0ngle wrote: post #529
tevon wrote: post #353

Currently if you visit the xz repository it is disabled for violating github's TOS. While it should clearly be disabled, I feel like github should leave the code and history up, while displaying a banner (and disabled any features that could be exploited), so that researchers and others can learn about the exploit. In more minor situations when a library is hosting malicious code, if I found the repo to be down I mig…

xz has its own git mirror where you can see all the commits

Notably only writable by Lasse who I personally believe is a Good Actor here.
Post reply on HN