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

671–680 of 862 posts

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

#671

Post by _kb »

dboreham wrote: post #291
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.

To me it seems too clumsy to be USG. They seem to prefer back doors that are undetectable or hide in plain sight. But it might be an NSA op designed to instigate a much needed serious examination of the supply chain.

That would honestly be one of the most impactful bits of public service to fall out of any agency, regardless of country. Even if this is nefarious, a couple of intentionally clumsy follow-ups designed to draw further attention would be amazing to see. Think chaos monkey for software supply chain.

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

#672

Post by lyu07282 »

supposemaybe wrote: post #387
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 (sp…

It was only in rolling release/testing/unstable distributions, a pretty small subset of systems in the grand scheme of things, is why I said that. It was introduced in February 23 release of xz. This could've been years until discovered.

Never use unstable/testing on real servers, that's a bad idea for entirely different reasons.

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

#673

Post by mslot »

klabb3 wrote: post #498
anarazel wrote: post #230

Earlier quoted context omitted.

The slowdown is actually in the startup of the backdoor, not when it's actually performing authentication. Note how in the original report even sshd -h (called in the right environment to circumvent countermeasures) is slow.

Wow. Given the otherwise extreme sophistication this is such a blunder. I imagine the adversary is tearing their hair out over this. 2-3 years of full time infiltration work down the drain, for probably more than a single person. As for the rest of us, we got lucky. In fact, it’s quite hilarious that some grump who’s thanklessly perf testing other people’s code is like “no like, exploit makes my system slower”.

You're responding to said grump ;)

Andres is one of the most prolific PostgreSQL committers and his depth of understanding of systems performance is second to none. I wouldn't have guessed he would one day save the world with it, but there you go.

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

#674

Post by rubymamis »

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.

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

#675

Post by formerly_proven »

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.

Honestly the only VPN I'd rank above ssh in terms of internet-worthiness is WireGuard.

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

#676

Post by grepLeigh »

I'm assuming nation states and similar actors monitor mailing lists for phrases like "I'm feeling burnt out" or "not enough bandwidth, can you open a PR?"

According to the timeline here, trust was established in "only" a few years. https://boehs.org/node/everything-i-know-about-the-xz-backdo...

So I imagine major actors already have other assets in at-risk open source projects, either for the source code or distro patch/packaging level. Is that too tinfoil hat? I only know enough about secops to be dangerous to myself and everyone around me.

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

#677

Post by sylware »

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.

I think you nailed it.

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

#678

Post by riedel »

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…

In a way this is really responsible backdoor. In the end this is even less dangerous than most unreported 0-days collected by public and private actors. Absurdly, I would feel reasonably safe with the compromised versions. Somebody selling botnet host would never be so careful to limit collateral damage.

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

#679

Post by password4321 »

BlueFalconHD wrote: post #222
plg94 wrote: post #129

Earlier quoted context omitted.

I don't think we know what exactly this does, yet. I can only answer one of those questions, as far as I understand the "unreplayable" part is refering to this: > Apparently the backdoor reverts back to regular operation if the payload is malformed or *the signature from the attacker's key doesn't verify*. emphasis mine, note the "signature of the attacker's key". So unless that key is leaked, or someone breaks the R…

It would be really cool if in 20 years when we have quantum computers powerful enough we could see what this exploit does.

AFAIK still no luck with Gauss from 2012

https://securelist.com/gauss-abnormal-distribution/36620/

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

#680

Post by goalieca »

tootie wrote: post #255
junon wrote: post #3

EDIT: Here's some more RE work on the matter. Has some symbol remapping information that was extracted from the prefix trie the backdoor used to hide strings. Looks like it tried to hide itself even from RE/analysis, too. https://gist.github.com/smx-smx/a6112d54777845d389bd7126d6e9... Full list of decoded strings here: https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01 -- For someone unfamiliar with openssl…

Mind boggling. How do you even decide what to do with privileges on a billion computers?

Government organizations have many different teams. One might develop vulnerabilities while another runs operations with oversight for approving use of exploits and picking targets. Think bureaucracy with different project teams and some multi-layered management coordinating strategy at some level.
Post reply on HN