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

381–390 of 862 posts

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

#381

Post by mjg59 »

cryptonector wrote: post #299
treasy wrote: post #216

Earlier quoted context omitted.

If you look at the diagram of privsep, the authentication process is part of the privileged binary, which is where this RCE lives http://www.citi.umich.edu/u/provos/ssh/priv.jpg

The signature validation could be moved into an unprivileged process forked from that one.

It wouldn't matter in this case, since the exploit could simply rewrite the function that calls out to the unprivileged process. If you already have malicious code in your privileged parent process there's no way to recover from that.

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

#382

Post by Randalthorro »

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…

You can find GitHub events from the repo as a csv here https://github.com/emirkmo/xz-backdoor-github

If you are interested in the source code that is easy to find. This code and git repo are linked all over the world, in many git repos, and the source is bundled many times in releases as well.

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

#383

Post by Randalthorro »

matrix_overload wrote: post #306
undersuit wrote: post #238

Earlier quoted context omitted.

Because in the closed source model the frustrated developer that looked into this SSH slowness submits a ticket for the owner of the malicious code to dismiss.

Not necessarily. A frustrated developer posts about it, it catches attention of someone who knows how to use Ghidra et al, and it gets dug out quite fast. Except, with closed-source software maintained by a for-profit company, suck cockup would mean a huge reputational hit, with billions of dollars of lost market cap. So, there are very high incentives for companies to vet their devs, have proper code reviews, etc. B…

Absolutely not. Getting a job at any critical infrastructure software dev company is easier than contributing to the Linux kernel.

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

#384

Post by Randalthorro »

cqqxo4zV46cp wrote: post #284
undersuit wrote: post #238

Earlier quoted context omitted.

Because in the closed source model the frustrated developer that looked into this SSH slowness submits a ticket for the owner of the malicious code to dismiss.

It’s insane to consider the actual discovery of this to be anything other than a lightning strike. What’s more interesting here is that we can say with near certainty that there are other backdoors like this out there.

Time to start looking at similar cases for sure.

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

#386

Post by takeda »

swid wrote: post #123
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…

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 could be wrong, buy my understanding is that it isn't even a door. It simply allows anyone that has a certain private key, to send a payload that the server will execute. This won't produce any audit of someone logging in, you won't see any session etc.

Any Linux with this installed would basically become a bot that can be taken over. Perhaps they could send a payload to make it DDoS another host, or payload to open a shell or payload that would install another backdoor with more functionality, and to draw attention away from this one.

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

#387

Post by supposemaybe »

lyu07282 wrote: post #365

God the amount of damage this would've caused, nightmarish, we are so unbelievably lucky. In a few months it would've been in every deb&rpm distribution. Thank God we found it early!

Found it early?..

I found the backdoor on five of my Vultr servers as well as my MacBook Pro this evening. I certainly didn’t catch it early.

So if that’s the state of it, it could very well be too late for many many companies. Not to mention folks who rely on TOR for their safety - there could be entire chains of backdoored entry, middle and exit nodes exposing vast numbers of TOR users over the past month or so (spies included!).

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

#389

Post by Randalthorro »

grepfru_it wrote: post #356
tootie wrote: post #139

Earlier quoted context omitted.

CISA had a report on this pretty quickly. I think they refer cases to Secret Service for enforcement. But really, we seemingly have no idea who or where the perpetrator is located. This could easily be a state actor. It could be a lone wolf. And the effects of the attack would be global too, so jurisdiction is tricky. We really have no idea at this point. The personas used to push the commits and push for inclusion w…

github retains an incredible amount of data to review. but if it is a state actor, they likely covered their tracks very well. when i found the original address of the person who hacked elon musk's twitter account it led to an amazon ec2 instance. that instance was bought with stolen financial information and accessed via several vpns and proxies. i would expect state actors to further obfuscate their tracks with she…

State actors get to invent people. Literally.
Post reply on HN