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

741–750 of 862 posts

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

#741

Post by yencabulator »

_nalply wrote: post #640
ezekg wrote: post #173

Earlier quoted context omitted.

As far as I can tell, the check is to see if a certain program compiles, and if so, disable something. The dot makes it so that it always fails to compile and thus always disables that something.

> if a certain program compiles, and if so, disable something. Tiny correction: [...] enable something. The idea is: If that certain program does not compile it is because something is not available on the system and therefore needs to be disabled. That dot undermines that logic. The program fails because of a syntax error caused by the dot and not because something is missing. It is easy to overlook because that dot…

> The solution: Check the errors carefully!

The desire for "does this compile on this platform" checks comes from an era where there was pretty much no way to check the error. Somebody runs it on HP-UX with the "HP-UX Ansi C Compiler" they licensed from HP and the error it spits out isn't going to look like anything you recognize.

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

#742

Post by djao »

someplaceguy wrote: post #513
teraflop wrote: post #278

Earlier quoted context omitted.

One of the biggest differences is that if you're using password auth, and you are tricked into connecting to a malicious server, that server now has your plaintext password and can impersonate you to other servers. If you use a different strong random password for every single server, this attack isn't a problem, but that adds a lot of management hassle compared to using a single private key. (It's also made more dif…

> if you're using password auth, and you are tricked into connecting to a malicious server, that server now has your plaintext password and can impersonate you to other servers. Why would the password be sent in plaintext instead of, say, sending a hash of the password calculated with a salt that is unique per SSH server? Or something even more cryptographically sound. In fact, passwords in /etc/shadow already do hav…

It's a little bit more complicated than just sending a hash of the password, but there are ways to authenticate using hashed passwords without sending the password over the wire, for example https://en.wikipedia.org/wiki/Digest_access_authentication or https://en.wikipedia.org/wiki/Password-authenticated_key_agr...

Even so, these protocols require the server to know your actual password, not just a hash of the password, even though the password itself never traverses the network. So a compromised server can still lead to a compromised credential, and unless you use different passwords for every server, we're back to the same problem.

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

#744

Post by djao »

dboreham wrote: post #285
danparsonson wrote: post #246

Earlier quoted context omitted.

Have to admit I've never understood why password auth is considered so much worse than using a cert - surely a decent password (long, random, etc) is for all practical purposes unguessable, and so you're either using a private RSA key that no-one can guess, or a password that no-one can guess, and then what's the difference? With the added inconvenience of having to pass around a certificate if you want to login to t…

It depends what happens to the password. Typically it's sent as a bearer credential. But there are auth schemes (not widely used these days) where the password isn't sent over the wire.

Even if you use a scheme where the password never traverses the wire, the schemes still require the server to know what your password is in order to perform the authentication. So a compromised server still leads to compromise of your secret credential. Public key authentication does not have this property.

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

#745

Post by Dalewyn »

djao wrote: post #737
Dalewyn wrote: post #569

Earlier quoted context omitted.

Except they weren't irresponsible. We all drove back just fine, and we all went back to work just as competently as before like nothing happened. It takes skill and maturity to have a good time but not so much that it would impair subsequent duties. The French demonstrated to me they have that down to a much finer degree than most of us have in America, so they have my respect. This isn't to say Americans are immatur…

As someone who knows people who died in a crash with another drunk driver, it is hard for me to accept your view. Certainly, at a bare minimum, the penalties for drunk driving that results in fatality should be much harsher than they are now -- at that point there is hard empirical evidence that you cannot be trusted to have the "skill and maturity" necessary for driving -- but we can't even bring ourselves to do tha…

I'm certainly not trying to understate the very real and very serious suffering that irresponsible drunk drivers can and do cause. If any of this came off like that then that was never my intention.

When it comes to understanding drunk driving and especially why it is de facto tolerated by society despite its significant problems, it's necessary to consider the motivators and both positive and negative results. Simply saying "they are all irresponsible and should stop" and such with a handwave isn't productive. After all, society wouldn't tolerate a significant problem if there wasn't a significant benefit to doing so.

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

#746

Post by yencabulator »

superb_dev wrote: post #223
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…

This feels very targeted

Untargeted (backdoor goes almost everywhere), but very selective (backdoor can only be triggered by the original attacker).

https://en.wikipedia.org/wiki/NOBUS

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

#747

Post by SeriousM »

tigerlily wrote: post #370

As a de facto maintainer of an obscure open source game, I see devs come and go. I just merge all the worthwhile contributions. Some collaborators go pretty deep with their features, with a variety of coding styles, in a mishmash of C and C++. I'm not always across the implementation details, but in the back of my mind I'm thinking, man, anyone could just code up some real nasty backdoor and the project would be scre…

To be honest, it just was a matter of time till we find out our good faith beliefs are exploited. Behaviors like "break fast and fix eary" or "who wants to take my peojeklct ownership" just ask for trouble and yet it's unthinkable to live without them because open source is an unpaid labor of love to code. Sad to see such happening but I'm not surprised. I wish to get better tools (also open source) to combat such bad actors. Thanks to all the researchers out there who tries to protect us all.

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

#748

Post by yencabulator »

cryptonector wrote: post #321
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…

I don't understand yet where the "unreplayable" part comes from, but this isn't it.

Replayable: You observe attack against server A, you can take that attack and perform it against server B.

This attack is unreplayable because it cryptographically ties into the SSH host key of the server.

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

#749

Post by dotancohen »

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…

The focus on the first S is good, yes, but SSH has another S and an H that needs focus as well.

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

#750

Post by xorcist »

CanaryLayout wrote: post #456
kbolino wrote: post #249

Earlier quoted context omitted.

Yes, this won't directly protect against an attacker whose goal is to create a botnet, mine some crypto on your dime, etc. However, it will protect against corruption of the O/S itself and, in tandem with other controls, can limit the abilities an attacker has, and ensure things like auditing are still enforced (which can be tied to monitoring, and also used for forensics). Whether it's worth it or not depends on cir…

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

OpenSSH has a much smaller attack surface, is thoroughly vetted by the best brains on the planet, and is privilege separated and sandboxed. What VPN software comes even close to that?

The only software remotely in the same league is a stripped down Wireguard. There is a reason the attacker decided to attack liblzma instead of OpenSSH.

Post reply on HN