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

721–730 of 862 posts

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

#721

Post by junon »

grepLeigh wrote: post #676

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

> Is that too tinfoil hat?

Not at all, no. This is probably happening way more than just this instance, unfortunately.

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

#722

Post by SV_BubbleTime »

kevincox wrote: post #410
SV_BubbleTime wrote: post #373

Earlier quoted context omitted.

> You know your password and so does the system authenticating you. Nitpick, but no it shouldn’t. The HASH of your password is recorded. You never submit your password, you submit that hash and they compare it. The difference is that there is no two passwords that collide; but there are hashes that may. And that two equal passwords from two equal users are not necessarily accessible to someone with the hash list beca…

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.

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

#723

Post by jethro_tell »

littlestymaar wrote: post #351
cryptonector wrote: post #299

Earlier quoted context omitted.

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

That's an easy thing to say after the fact indeed but yes. In fact after such a disastrous backdoor I wouldn't be surprised if OpenSSH moved all code calling external libraries to unprivileged processes to make sure such an attack can never have such a dramatic effect (an auth bypass would still likely be possible, but that's still way better than a root RCE…). At this point “All libraries could be malicious” is a th…

Openssh has refused this patch that enables this in Debian multiple times as acrisk of preauth code execution as root.

So maybe just don't patch sshd?

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

#724

Post by jethro_tell »

CanaryLayout wrote: post #437
asveikau wrote: post #416

Earlier quoted context omitted.

I don't think that's a threat model that OpenSSH should waste too much time on. Ultimately this is malicious code in the build machine compiling a critical system library. That's not reasonable to defend against. Keep in mind that upstream didn't even link to liblzma. Debian patched it to do so. OpenSSH should defend against that too?

any one of us if we sat on the OSSH team would flip the middle finger. What code is the project supposed to write when nothing on main dyn loaded liblzma. It was brought in from a patch they don't have realistic control over. This is a Linux problem, and the problem is systemd, which is who brought the lib into memory and init'd it.

Brought in from a patch they rejected to accept because of this exact risk

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

#725

Post by semiquaver »

ajross wrote: post #705
dotancohen wrote: post #667

Earlier quoted context omitted.

I need full filesystem access, VIM, ls, cd, grep, awk, df, du at the very least. Sometimes perl, find, ncdu, and other utilities are necessary as well. Are you suggesting that each tool have its own SSH process wrapping it? Maybe write a shell to coordinate between them? It should support piping and output redirection, please.

Sigh. I'm not saying there's a sandboxed sshd setup that has equivalent functionality to the default one in your distro. I'm not even saying that there's one appropriate for your app. I'm saying, as a response to the point above, that sandboxing sshd is absolutely a valid defense-in-depth technique for privilege isolation, that it would work against attacks like this one to prevent whole-system exploitation, and that…

Git’s use of the ssh protocol as a transport is a niche use case that ignores the actual problem. No one is seriously arguing that you can’t sandbox that constrained scenario but it’s not really relevant since it’s not the main purpose of the secure shell daemon.

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

#726

Post by BuildTheRobots »

dannyw wrote: post #588
BuildTheRobots wrote: post #316

Earlier quoted context omitted.

I'm a little out of touch, but for over a decade I'd say half the boxes I touched either didn't have enough entropy or were trying to do rDNS for (internal) ranges to servers that didn't host it and is nearly always hand waved away by the team running it as NFN. That is to say, a half-second pause during the ssh login is absolutely the _least_ suspicious place place for it to happen and I'm somewhat amazed anyone tho…

What led to continuous investigation wasn't just the 500ms pause, but large spikes in CPU activity when sshd was invoked, even without a login attempt.

What lead to it was the fact he was already micro-benchmarking postgresql along with a couple of other bits of fluke. We were all extremely lucky.

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

#727

Post by guenthert »

NekkoDroid wrote: post #626
guenthert wrote: post #621

Earlier quoted context omitted.

Hmmh, brings up the question, if no exploit actually occurred, was a crime committed? Can't the authors claim that they were testing how quickly the community of a thousand eyes would react, you know, for science?

That's like asking if someone that went into a crowded place with a full-automatic and started shooting at people but "purposefully missing" is just testing how fast law enforcement reacts, you know, for science. After something like 2 years of planning this out and targeted changes this isn't something "just done for science".

Or is it rather like someone posting a video on youtube on how to pick a common lock?

And what's about the fellows of U of Minnesota?

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

#728

Post by matheusmoreira »

krick wrote: post #709
matheusmoreira wrote: post #707

Earlier quoted context omitted.

Not really. Just make your software AGPLv3. It's literally the most free license GNU and the FSF have ever come up with. It ensures your freedom so hard the corporations cannot tolerate it. Now you have leverage. If the corporations want it so bad, they can have it. They just gotta ask for permission to use it under different terms. Then they gotta pay for it. https://www.gnu.org/philosophy/selling-exceptions.html Al…

The problem is, there will be almost zero packages that (very few) "corporations want so bad". The only exception might be cloud providers, that want to host your mildly-popular open-source message queue, but, again, if you are Amazon, you'll soon just re-implement that message queue, drop the "original" one, and after a couple of years your mildly-popular project will become not popular at all.

In that case we'll simply end up exactly where we started. There's a twist though. This time around we're not being taken for fools and exploited.

Better to have a completely irrelevant forgotten project than a massively popular one that makes us zero dollars while CEOs make billions off of it.

This post always comes to mind every time this topic comes up:

https://web.archive.org/web/20120620103603/http://zedshaw.co...

> I want people to appreciate the work I’ve done and the value of what I’ve made.

> Not pass on by waving “sucker” as they drive their fancy cars.

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

#729

Post by circusfly »

circusfly wrote: post #385

Could the backdoor have targeted Wireguard instead of ssh?

Down voted for asking a valid question? Or is every reader of every HN post expected to be an in depth expert in every article posted every minute of every day of the year? What kind of asshole who has earned the right to down vote comments on HN would down vote a legitimate question?

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

#730

Post by chii »

sgammon wrote: post #484
sgammon wrote: post #440

There appears to be a string encoded in the binary payload: https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01... Which functions as a killswitch: https://piaille.fr/@zeno/112185928685603910 If that is indeed the case, one mitigation might be ``` echo "yolAbejyiejuvnup=Evjtgvsh5okmkAvj" | sudo tee -a /etc/environment ```

Make absolutely sure to include `-a` so it doesn't nuke your env file, and generally speaking, one should upgrade to a version without the malicious code and restart, of course.

> without the malicious code and restart

i wonder if the malicious code would've installed a more permanent backdoor elsewhere that would remain after a restart.

I recall things like on windows where malware would replace your keyboard drivers or mouse drivers with their own ones that had the malware/virus, so that even if the original malware is removed, the system is never safe again. You'd have to wipe. And this is not even counting any firmware that might've been dropped.

Post reply on HN