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

551–560 of 862 posts

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

#551

Post by Deathcrow »

sebiw wrote: post #90
paolomainardi wrote: post #79

I am wondering if reinstalling the entire Archlinux installation would be a wise choice.

Arch Linux uses a native/unpatched version of OpenSSH without dependency on libsystemd and thus without dependency on xz-utils, resulting in no exploitable code path. This means that at least the currently talked about vulnerability/exploit via SSH did presumably not work on Arch. Disclaimer: This is my understanding of the currently circulating facts. Additional fallout might be possible, as the reverse engineering…

This is only correct if the sshd backdoor is the only malicious code introduced into the library.

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

#552

Post by Cloudef »

Nathanba wrote: post #394
swid wrote: post #123

Earlier quoted context omitted.

You can imagine a door that opens if you knock on it just right. For anyone without the secret knock, it appears and functions as a wall. Without the secret knock, there might not even be a way to prove it opens at all. This is sort of the situation here. xz tries to decode some data before it does anything shady; since it is asymmetric; it can do the decryption without providing the secret encryption key (it has the…

I understand that we may never see the secret knock but shouldn't we have the door and what's behind it now? Doesn't this mean that the code is quite literally too hard to figure out for a human being? It's not like he can send a full new executable binary that he simply executes, then we'd see that the door is e.g the exec() call. Honestly this attempt makes me think that the entire c/c++ language stack and ecosyste…

Nothing here is something that could not be done in other languages. For example in Rust auditing this kind of supply chain attack is even more nightmarish if the project uses crates, as crates often are very small causing the "npm effect".

Another good example is docker images. The way people often build docker images is not that they are build all the way from the bottom. The bottom layer(s) is/are often some arbitrary image from arbitrary source which causes a huge supply chain attack risk.

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

#553

Post by Too »

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…

A lot of it has to do with centralizing administration. If you have more than one server and more than one user, certificates reduce a NxM problem into N+M instead.

Certificates can be revoked, they can have short expiry dates and due to centralized administration, renewing them is not terribly inconvenient.

On top of that they are a lot more difficult to read over the shoulder, to some degree that can be considered the second factor in a MFA scheme. Same reasons why passkeys are preferred over passwords lately. Not as secure as a HW-key, still miles better than “hunter2”.

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

#554

Post by kijin »

nequo wrote: post #378
XorNot wrote: post #288

Earlier quoted context omitted.

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 fun…

Might a time-sensitive high-priority goal override such reasoning? For example, the US presidential election is coming up. Making it into Ubuntu LTS could be worth the risk if valuable government targets are running that.

Jia Tan tried to get his backdoored XZ into Ubuntu 24.04 just before the freeze, so that makes sense. Now is about the right time to get it into Fedora if he wants to backdoor RHEL 10, too.

But I don't think valuable government targets are in any hurry to upgrade. I wouldn't expect widespread adoption of 24.04, even in the private sector, until well after the U.S. election.

By the next election, though, everyone will be running it.

Edit: According to another comment [1], there would only have been a short window of vulnerability during which this attack would have worked, due to changes in systemd. This might have increased pressure on the attacker to act quickly.

[1] https://news.ycombinator.com/item?id=39881465

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

#555

Post by keiba »

rany_ wrote: post #286

If my server doesn't have any RSA public keys in its authorized_keys, only ed25519 keys; does this backdoor just not work?

This backdoor does not care about any of the authorisation configuration set by the user.

It is executed before that step. So just make sure you are not affected.

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

#556

Post by kbenson »

Dalewyn wrote: post #543
Karrot_Kream wrote: post #455

Earlier quoted context omitted.

This is such a deeply American take that I can't help but laugh out loud. It's like going to a developing nation and saying that, while emissions from two stroke scooters kills people there's no alternative to get your life things done.

It certainly isn't just America, though we're probably certainly the most infamous example. I was in France for business once in the countryside (southern France), and the host took everyone (me, their employees, etc.) out to lunch. Far as I could tell it was just an everyday thing. Anyway, we drove about an hour to a nearby village and practically partied for a few hours. Wine flowed like a river. Then we drove back…

> Even Americans usually don't drink that hard; the French earned my respect that day.

Is drinking hard something so deserving of respect? Is working while impaired?

To me this reads as "I like to fuck off and be irresponsible and man did these French guys show me how it's done!"

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

#557

Post by ivlad »

amscanne wrote: post #527
ivlad wrote: post #471

Earlier quoted context omitted.

This would be execve() that did not go through PAM dance and end up being privileged process. I _think_ it’ll look very different in ps —-forest output.

It’s true that there’s a precise set of circumstances that would be different for the RCE (the lack of a PAM dance prior, same process group & session, no allocation of a pseudo-terminal, etc.). My point was merely that I don’t think they are commonly encoded in rule sets or detection systems. It’s certainly possible, but my guess is sshd is likely to have a lot of open policy. I’m really curious if someone knows dif…

I am trying to figure out if auditctl is expressive enough to catch unexpected execve() from sshd: basically anything other than /usr/bin/sshd (for privsep) executed with auid=-1 should be suspicious.

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

#558

Post by numpad0 »

Muromec wrote: post #494
pcthrowaway wrote: post #170

Earlier quoted context omitted.

Based on the level of sophistication being alluded to, I'm personally inclined to assume this is a state actor, possible even some arm of the U.S. govt.

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

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

#559

Post by forty »

tialaramex wrote: post #355
swid wrote: post #123

Earlier quoted context omitted.

You can imagine a door that opens if you knock on it just right. For anyone without the secret knock, it appears and functions as a wall. Without the secret knock, there might not even be a way to prove it opens at all. This is sort of the situation here. xz tries to decode some data before it does anything shady; since it is asymmetric; it can do the decryption without providing the secret encryption key (it has the…

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…

I have often seen the secret component of an asymmetric key pair referred as secret key as well. See libsodium for example. Maybe it's because curve/ed 25519 secrets are 32 random bytes unlike RSA keys which have specific structure which makes them distinct from generic secrets.

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

#560

Post by adtac »

rany_ wrote: post #286

If my server doesn't have any RSA public keys in its authorized_keys, only ed25519 keys; does this backdoor just not work?

It will still work if the connecting client offers a RSA key.

The only real way to be sure it's not on your system is if your liblzma version is strictly less than 5.6.0 (first infected version):

    ls -al $(ldd $(which sshd) | grep lzma | awk '{ print $3 }')
Post reply on HN