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

201–210 of 862 posts

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

#201

Post by slooonz »

1oooqooq wrote: post #101
wiktor-k wrote: post #22

> OpenSSH certs are weird in that they include the signer's public key. OpenSSH signatures in general contain signer's public key, which I personally think it's not weird but rather cool since it allows verifying the signature without out of the band key delivery (like in OpenPGP). The authentication of the public key is a separate subject but at least some basic checks can be done with an OpenSSH signature only.

> cool since it allows verifying the signature without out of the band key delivery hope you do key selection sanitization instead of the default (nobody does). otherwise you're accepting random keys you have laying around (like github) when logging to secret.example.com

What do you mean ?

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

#202

Post by pcthrowaway »

tejohnso wrote: post #192
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.

> possible even some arm of the U.S. govt. Possible. But why mention U.S. specifically? Is it more likely than Russia, Iran, China, France ... ?

> This individual/organization needs to be on the top of every country's most wanted lists

Because if the "organization" is a U.S. agency, not much is going to happen here. Russia or China or North Korea might make some strongly worded statements, but nothing is going to happen.

It's also very possible that security researchers won't be able to find out, and government agencies will finger-point as a means of misdirection.

For example, a statement comes out in a month that this was North Korea. Was it really? Or are they just a convenient scapegoat so the NSA doesn't have to play defense on its lack of accountability again?

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

#203

Post by empath-nirvana »

noncoml wrote: post #14

Unpopular opinion, but I cannot but admire the whole operation. Condemn it of course, but still admire it. It was a piece of art! From conception to execution, masterful! We got extremely lucky that it was caught so early.

I don't think "admire" is the right word, but it's a pretty impressive operation.

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

#204

Post by pessimizer »

TheBlight wrote: post #76
baq wrote: post #70

Earlier quoted context omitted.

> But why would a government want to own tons of random Linux machines that have open sshd mappings? They don’t want tons. They want the few important ones. Turns out it was easiest to get to the important ones by pwning tons of random ones.

That still implies there was a target in mind. But also they would've had to assume the access would be relatively short-lived. This means to me they had something specific they wanted to get access to, didn't plan to be there long, and weren't terribly concerned about leaving a trail of their methods.

Why couldn't they have had 50 or 100 targets in mind, and hoped that the exploit would last for at least the month (or whatever) they needed to accomplish their multiple, unrelated goals?

I think your imagination is telling you a story that is prematurely limiting the range of real possibilities.

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

#205

Post by empath-nirvana »

asveikau wrote: post #27

I have found it irritating how in the community, in recent years, it's popular to say that if a project doesn't have recent commits or releases that something is seriously wrong. This is a toxic attitude. There was nothing wrong with "unmaintained" lzma two years ago. The math of the lzma algorithm doesn't change. The library was "done" and that's ok. The whiny mailing list post from the sock puppet, complaining abou…

2 popular and well tested rust yaml libraries have recently been marked as unmaintained and people are moving away from them to brand new projects in a rush because warnings went out about it.

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

#206

Post by asveikau »

saltcured wrote: post #180
semiquaver wrote: post #100

Earlier quoted context omitted.

Could you explain how SELinux could ever sandbox against RCE in sshd? Its purpose is to grant login shells to arbitrary users, after all.

You could refactor sshd so most network payload processing is delegated to sandboxed sub-processes. Then an RCE there has less capabilities to exploit directly. But, I think you would have to assume an RCE can cause the sub-process to produce wrong answers. So if the answers are authorization decisions, you can transitively turn those wrong answers into RCE in the normal login or remote command execution context. But…

I thought that OpenSSH's sshd already separates itself into a privileged process and a low-privilege process. I don't know any details about that. Here's what Google showed me for that: https://github.com/openssh/openssh-portable/blob/master/READ...

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

#208

Post by kbolino »

admax88qqq wrote: post #161
ajross wrote: post #148

Earlier quoted context omitted.

It's possible to spawn a sshd as an unprivileged or partially-capabilitized process. Such as sandbox isn't the default deployment, but it's done often enough and would work as designed to prevent privilege elevation above the sshd process.

How can sshd spawn interactive sessions for other users if it's sandboxed?

SELinux does not rely on the usual UID/GID to determine what a process can do. System services, even when running as "root", are running as confined users in SELinux. Confined root cannot do anything which SELinux policy does not allow it to do. This means you can let sshd create new sessions for non-root users while still blocking it from doing the other things which unconfined root would be able to do. This is still a lot of power but it's not the godlike access which a person logged in as (unconfined) root has.
Post reply on HN