XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable." • Hacker News Board

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

#591

Post by geggo98 » Sun, Mar 31, 2024, 7:47 AM UTC

sega_sai wrote: post #95

One have question on this is, if the backdoor would not been discovered due to performance issue (which was as I understood it purely an oversight/fixable deficiency in the code), what are the chances of discovering this backdoor later, or are there tools that would have picked it up? Those questions are IMO relevant to understand if this kind of backdoor is the first one of the kind, or the first one that was uncove…

Using a jump host could help, only allowing port forwarding. Ideally it would be heavily monitored and create a new instance for every connection (e.g., inside a container).

The attacker would then be stuck inside the jump host and would have to probe where to connect next. This hopefully would then trigger an alert, causing some suspicion.

A shared instance would allow the attacker to just wait for another connection and then follow its traces, without risking triggering an alert by probing.

The ideal jump host would allow to freeze the running ssh process on an alert, either with a snapshot (VM based) or checkpointing (container based), so it can be analyzed later.

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

#592

Post by tomasGiden » Sun, Mar 31, 2024, 7:47 AM UTC

nrdvana wrote: post #459

saltcured wrote: post #180

Earlier quoted context omitted.

You could refactor sshd so most network payload processing is delegated to sandboxed sub-processes. Then an RCE there has less capabilities to exploit directly. But, I think you would have to assume an RCE can cause the sub-process to produce wrong answers. So if the answers are authorization decisions, you can transitively turn those wrong answers into RCE in the normal login or remote command execution context. But…

That just raises the hurdle for the attacker. The attacker in this case has full control to replace any function within ssh with their own version, and the master process of sshd will always need the ability to fork and still be root on the child process before dropping privileges. I don't see any way around that. They only needed to override one function this time, but if you raise the bar they would just override m…

I’m highly safety critical systems you have software (and hardware) diversity were multiple pieces of software, developed independently, have to vote on the result. Maybe highly critical pieces of Linux like the login process should be designed the same way. So that two binaries without common dependencies would need to accept the login for the user to get privileges.

Exactly how to do it (especially transparently for the user), I have no idea though. Maybe sending ssh login requests to two different sshd implementations and if they don’t do the same things (same system calls), they are both killed.

Or some kind of two step login process where the first login only gives access to the sandbox of the second login process.

But in general I assume the Linux attack surface is too big to do software diversity for all of it.

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

#593

Post by t0mas88 » Sun, Mar 31, 2024, 7:49 AM UTC

cryptonector wrote: post #335

I'm surprised the attackers used Ed448 instead of Ed25519.

Maybe their organisation has a policy that requires stronger encryption? Possibly because that organisation is also in the business of cracking such encryption...

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

#594

Post by bostik » Sun, Mar 31, 2024, 7:52 AM UTC

danparsonson wrote: post #246

tialaramex wrote: post #17

Earlier quoted context omitted.

One completely awful thing some scanners might choose to do is if you're offering RSA auth (which most SSH servers are and indeed the SecSH RFC says this is Mandatory To Implement) then you're "potentially vulnerable" which would encourage people to do password auth instead. Unless we find that this problem has somehow infested a lot of real world systems that seems to me even worse than the time similar "experts" de…

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…

> surely a decent password (long, random, etc) is for all practical purposes unguessable

Sadly that is not how normies use passwords. WE know what passwords managers are for. Vast majority of people outside our confined sphere do not.

In short: password rotation policies make passwords overall less secure, because in order to remember what the new password is, people apply patterns. Patterns are guessable. Patterns get applied to future password as well. This has been known to the infosec people since 1990's because they had to understand how people actually behave. It took a research paper[0], published in 2010, to finally provide sufficient data for that fact to become undeniable.

It still took another 6-7 years until the information percolated through to the relevant regulatory bodies and for them to update their previous guidance. These days both NIST and NCSC tell in very clear terms to not require password rotation.

0: https://www.researchgate.net/publication/221517955_The_true_...

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

#595

Post by FeepingCreature » Sun, Mar 31, 2024, 7:52 AM UTC

Cloudef wrote: post #570

kbenson wrote: post #541

Earlier quoted context omitted.

That this was dynamically linked is the least interesting thing about it IMO. It was a long term I filtration where they got legitimate commit access to a well used library. If xz was statically linked in some way, or just used as an executa Le to compress something (like the kernel), the same problems exist and no dynamic linking would need to be involved.

Not true, it would be much harder to hook into openssl functions if the final executable was static [1], the only way is that if the openssl function this attack targeted, actually called a function from libxz. [1] https://sourceware.org/glibc/wiki/GNU_IFUNC Dynamic loading is relic of the past and cause of many headaches in linux ecosystem, in this case it also just obfuscates the execution path of the code more so…

Looking at IFUNC, there never seems to be a reason to allow function loading from a different library than the one the call is in, right? Maybe a restriction like that could be built in. Or just explicitly enumerate the possible substitutions per site.

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

#596

Post by perbu » Sun, Mar 31, 2024, 7:55 AM UTC

juliusdavies wrote: post #589

Lucky the XZ license switched from "Public Domain" to 0BSD in February (just before these 5.6.0 and 5.6.1 releases)! 0BSD has no clauses, but it does have this: > IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF O…

Gross negligence and willfull misconduct cannot be waved away like this, in certain legislations, at least.

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

#597

Post by juliusdavies » Sun, Mar 31, 2024, 7:57 AM UTC

perbu wrote: post #596

juliusdavies wrote: post #589

Lucky the XZ license switched from "Public Domain" to 0BSD in February (just before these 5.6.0 and 5.6.1 releases)! 0BSD has no clauses, but it does have this: > IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF O…

Gross negligence and willfull misconduct cannot be waved away like this, in certain legislations, at least.

Yes, but hopefully it does protect Lasse Collin.

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

#598

Post by mr_mitm » Sun, Mar 31, 2024, 7:57 AM UTC

SV_BubbleTime wrote: post #373

tialaramex wrote: post #355

Earlier quoted context omitted.

Private key. In cryptography we distinguish keys which are symmetric (needed by both parties and unavailable to everyone else) as "Secret" keys, with the pair of keys used in public key cryptography identified as the Private key (typically known only to one person/ system/ whatever) and Public key (known to anybody who cares) Thus, in most of today's systems today your password is a secret . You know your password an…

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

> You never submit your password, you submit that hash and they compare it.

That's not true. If that were the case, the hash is now the password and the server stores it in clear text. It defeats the entire purpose of hashing passwords.

Side note: that is (almost) how NTLM authentication works and why pass-the-hash is a thing in Windows networks.

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

#599

Post by takeda » Sun, Mar 31, 2024, 7:58 AM UTC

junon wrote: post #263

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…

Siblings saying "we don't know" haven't really groked the post I don't think. If I'm understanding the thread correctly, here's a (not so) succinct explanation. Please, if you know better than I do, correct me if I've made an error in my understanding. `system()` is a standard C function that takes a string as input and runs it through `sh`, like so: sh -c "whatever input" It's used as a super rudimentary way to run…

> They'd effectively have a skeleton key that only they could use (or sell) that

this looks more like state sponsored attack and it doesn't look like someone joining and at one point realizing they want to implement this backdoor.

The guy joined the project 2 years ago, developed a test framework (which he then used to hide binary of the backdoor in which appears that is complex and others are still figuring out how it works) then he gradually disabled various security checks before activating it.

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

#600

Post by mitjam » Sun, Mar 31, 2024, 7:58 AM UTC

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”.

If it was not fulltime work I wonder what else they have been working on with different accounts.