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

781–790 of 862 posts

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

#781

Post by crotchfire »

nullc wrote: post #701
zettabomb wrote: post #685

Earlier quoted context omitted.

Can we stop the ridiculous C++ fearmongering? You can make vulnerable software in any language, and you can do social engineering on any software.

The people who are busy inserting backdoors in all the "rewrite it in rust" projects where anonymous never heard from before new to programming randos rewrite long trusted high security projects in rust would presumably very much like everyone elses attention directed elsewhere.

It's okay, the Cargo Lords promise me that because they require a git-hub account and agreeing to the git-hub terms of service before contributing, everything will be okay.

They pinky-swear.

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

#782

Post by tialaramex »

SV_BubbleTime wrote: post #722
kevincox wrote: post #410

Earlier quoted context omitted.

To really nitpick the server does have the password during authentication. The alternate would be a PAKE which is currently quite rare. (But probably should become the standard)

I was going more for shouldn’t . You’re right, but for zero knowledge things like password managers where they specifically do not want your password.

I am aware of PAKEs, and I decided not to waste my time mentioning them because as usual the situation is:

Using a PAKE correctly would be safe, but that sounds like work

Just saying "Use a good password" is no work and you can pretend it's just as safe.

Real world systems using a PAKE are very rare. The most notable is WPA3 (and there are numerous scenarios where it's for nothing until WPA2 is long obsolete). Lots of systems which would use a PAKE if designed by a cryptographer were instead designed by engineers or managers for whom "Ooh, a hash with salt" sounds like a sophisticated modern technical solution rather than a long obsolete one.

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

#783

Post by computerfriend »

sureglymop wrote: post #535
computerfriend wrote: post #488

Earlier quoted context omitted.

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

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

The enlightenment has happened in the other comments, but the summary is:

* this enforces high entropy,

* the password is transmitted to the server, the private key is not.

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

#784

Post by salawat »

astrange wrote: post #764
dotancohen wrote: post #660

Earlier quoted context omitted.

That does not sound like the type of machine that I want to work on. I still require a general purpose computer.

Why does a general purpose computer need to overwrite crypto functions in sshd?

Because it's a general purpose computer. Duh. The aim is to be able to arbitrary computations. Which overwriting crypto functions in sshd is a valid computation to be considered.

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

#785

Post by Thorrez »

candiodari wrote: post #57
Thorrez wrote: post #51

Earlier quoted context omitted.

The tweet says "unreplayable". Can someone explain how it's not replayable? Does the backdoored sshd issue some challenge that the attacker is required to sign?

What it does is this: RSA_public_decrypt verifies a signature on the client's (I think) host key by a fixed Ed448 key, and then if it verifies, passes the payload to system(). If you send a request to SSH to associate (agree on a key for private communications), signed by a specific private key, it will send the rest of the request to the "system" call in libc, which will execute it in bash. So this is quite literall…

That sounds repayable though. If I did a tcpdump of the attacker attacking my system, I could replay that attack against someone other system. For it to not be replayable, there needs to be some challenge issued by the backdoored sshd.

Of course since the backdoor was never widely deployed and is now public, I think it's unlikely the attacker will attempt to use it. So whether it's replayable doesn't have a practical impact now. I'm only asking about replayability because I'm curious how it's unreplayable.

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

#786

Post by yborg »

rigid wrote: post #641
lazyasciiart wrote: post #631

Earlier quoted context omitted.

How do you mean?

I bet in the majority of cases, there's no need to pressure for merging. In a big company it's much easier to slip it in. Code seemingly less relevant for security is often not reviewed by a lot of people. Also, often people don't really care and just sign it off without a closer look. And when it's merged, no one will ever look at it again, other than with FOSS.

An insider could just be tasked to look for exploitable vulnerabilities in existing code and compile this information for outside entities without ever having to risk inserting a purpose-made backdoor. Considering the security state of most large codebases, there would be a bottomless well of them.

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

#787

Post by bee_rider »

Muromec wrote: post #492
ecshafer wrote: post #314

Earlier quoted context omitted.

That is an interesting solution. If China, US, Russia, EU, etc all sign off and say "yep this is secure" we should trust it. Since if they think they found an exploit, they might assume the other people found an exploit. This is a little bit like the idea of a fair cut for a cake. If you have two people that want the last slice of cake, you have one cut and the other choose the first slice, since the chooser will cho…

NSA makes the cut and China picks the public key to use. In all seriousness, those people will quickly find some middle ground and will just share keys with each other

Maybe also throw EFF into the mix.

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

#788

Post by astrange »

salawat wrote: post #784
astrange wrote: post #764

Earlier quoted context omitted.

Why does a general purpose computer need to overwrite crypto functions in sshd?

Because it's a general purpose computer. Duh. The aim is to be able to arbitrary computations. Which overwriting crypto functions in sshd is a valid computation to be considered.

I don't think you should connect your general purpose computer to the internet then. Or keep any valuable data on it. Otherwise other people are going to get to perform computations on it.

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

#789

Post by astrange »

rwmj wrote: post #653
astrange wrote: post #511

Earlier quoted context omitted.

It is possible to prevent libraries from patching functions in other libraries; make those VM regions unwritable, don't let anyone make them writable, and adopt PAC or similar hardware protection so the kernel can't overwrite them either.

That's already done, but in this case the attack happened in a glibc ifunc and those run before the patching protection is enabled (since an ifunc has to patch the PLT).

Sounds like libraries should only get to patch themselves.

(Some difficulty with this one though. For instance you probably have to ban running arbitrary code at load time, but you should do this anyway because it will stop people from writing C++.)

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

#790

Post by 1oooqooq »

ykonstant wrote: post #616
1oooqooq wrote: post #547

Earlier quoted context omitted.

edit your .ssh/config. add one Host entry per domain. on the end of the file add one catch all host rule with IdentityFile /dev/null otherwise you're sending default key names to all hosts. ...and you are not sending id_rsa.pub to every single place you add a key, like most guides suggests, right? right?

I would be interested in a comprehensive guide on "doing it right", or a link to a guide that suggests the right thing.

already exists. "man sshconfig" or something.

guides dumbing down things are the root of evil.

Post reply on HN