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

651–660 of 862 posts

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

#651

Post by skywhopper »

xinayder wrote: post #636
skywhopper wrote: post #128

Earlier quoted context omitted.

From what I’ve read I think the attack vector is: 1. sshd starts and loads the libsystemd library which loads the XZ library which contains the hack 2. The XZ library injects its own versions of functions in openssl that verify RSA signatures 3. When someone logs into SSH and presents a signed SSH certificate as authentication, those hacked functions are called 4. The certificate, in turn, can contain arbitrary data…

> When someone logs into SSH and presents a signed SSH certificate as authentication, those hacked functions are called So if I only use pubkey auth and ED25519, there's no risk? Besides this, just to understand it better, if someone tries to login to your server with the attacker's certificate, the backdoor will disable any checks for it and allow the remote user to login as root (or any other arbitrary user) even i…

I don’t think we know enough to be sure even disabling certificate auth would prevent this. But from what I can tell it probably wouldn’t directly allow arbitrary user login. It only seems to allow the execution of an arbitrary command. But of course that command might do something that would break any other security on the system.

But, one clever thing about this attack is that the commands being run wouldn’t be caught by typical user-login tracking, since there’s no “login”. The attacker is just tricking sshd into running a command.

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

#652

Post by skywhopper »

Deathcrow wrote: post #540
ghostpepper wrote: post #189

Earlier quoted context omitted.

> beyond the (presumably failed) login attempt There is some evidence it's scrubbing logs so we might not even have that.

Is there really a failed login attempts? If it never calls the real functions of ssh in case of their own cert+payload why would sshd log anything or even register a login attempt? Or does the backdoor function hook in after sshd already logged stuff?

I think it would depend on logging level, yeah. I’ve not seen one way or another whether it aborts the login process or prevents logging, but that’s possible, and would obviously be a good idea. Then the question would be if you could detect the difference between a vulnerability-aborted login attempt and just a malformed/interrupted login attempt.

But in the case of this specific attack, probably the safest approach would be to watch and track what processes are being spawned by sshd. Which in retrospect is probably advisable for any network daemon. (Of course, lots of them will be sloppy and messy with how they interact with the system and it might be next to impossible to tell attacks from “legit” behavior. But sshd is probably easier to pin down to what’s “safe” or not.

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

#653

Post by rwmj »

astrange wrote: post #511
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?

It is possible to prevent libraries from patching functions in other libraries; make those VM regions unwritable, don't let anyone make them writable, and adopt PAC or similar hardware protection so the kernel can't overwrite them either.

That's already done, but in this case the attack happened in a glibc ifunc and those run before the patching protection is enabled (since an ifunc has to patch the PLT).

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

#654

Post by denton-scratch »

pxc wrote: post #514
sitkack wrote: post #220

Earlier quoted context omitted.

Why would the FBI investigate the NSA? We have zero idea who the actors involved are.

It's not actually unusual for three-letter US agencies to be at odds with one another. But one possible reason is if the FBI is convinced that something the NSA is doing is illegal. They may not always be inclined to tolerate that.

> It's not actually unusual for three-letter US agencies to be at odds with one another.

I'd noticed that; this seems to have been the case for a long time. You'd think that having state security agencies at war with one-another would be a disaster, but perhaps it's a feature: a sort of social "layered security". At any rate, it seems much better than having a bunch of state security agencies that all sing from the same songsheet.

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

#655

Post by amelius »

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…

Backdoors can be placed in any type of software. For example, a GIMP plugin could connect to your display and read keystrokes, harvest passwords, etcetera. Utilities run by the superuser are of course even more potentially dangerous. Supply-chain attacks like these are just bound to happen. Perhaps not as often in SSH which is heavily scrutinized, but the consequences can be serious nevertheless.

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

#656

Post by imiric »

p-e-w wrote: post #474
imiric wrote: post #452

Earlier quoted context omitted.

> When you're taking a walk on a forest road, any car that comes your way could just run you over. Chances are the driver would never get caught. There is nothing you can do to protect yourself against it. Sure you can. You can be more vigilant and careful when walking near traffic. So maybe don't have headphones on, and engage all your senses on the immediate threats around you. This won't guarantee that a car won't…

It's not defeatist to admit and accept that some things are ultimately out of our control. And more importantly, that any attempt to increase control over them comes with downsides. An open source project that imposes all kinds of restrictions and complex bureaucratic checks before anything can get merged, is a project I wouldn't want to participate in. I imagine many others might feel the same. So perhaps the loss f…

> It's not defeatist to admit and accept that some things are ultimately out of our control.

But that's the thing: deciding how software is built and which features are shipped to users _is_ under our control. The case with xz was exceptionally bad because of the state of the project, but in a well maintained project having these checks and oversight does help with delivering better quality software. I'm not saying that this type of sophisticated attack could've been prevented even if the project was well maintained, but this doesn't mean that there's nothing we can do about it.

> And more importantly, that any attempt to increase control over them comes with downsides.

That's a subjective opinion. I personally find linters and code reviews essential to software development, and if you think of them as being restrictions or useless bureaucratic processes that prevent you from contributing to a project then you're entitled to your opinion, but I disagree. The downsides you mention are simply minimum contribution requirements, and not having any at all would ultimately become a burden on everybody, lead to a chaotic SDLC, and to more issues being shipped to users. I don't have any empirical evidence to back this up, so this is also "just" my opinion based on working on projects with well-defined guidelines.

I'm sure you would agree with the Optimistic Merging methodology[1]. I'd be curious to know whether this has any tangible benefits as claimed by its proponents. At first glance, a project like https://github.com/zeromq/libzmq doesn't appear to have a more vibrant community than a project of comparable size and popularity like https://github.com/NixOS/nix, while the latter uses the criticized "Pessimistic Merging" methodology. Perhaps I'm looking at the wrong signals, but I'm not able to see a clear advantage of OM, while I can see clear disadvantages of it.

libzmq does have contribution guidelines[2], but a code review process is unspecified (even though it mentions having "systematic reviews"), and there are no testing requirements besides patches being required to "pass project self-tests". Who conducts reviews and when, or who works on tests is entirely unclear, though the project seems to have 75% coverage, so someone must be doing this. I'm not sure whether all of this makes contributors happier, but I sure wouldn't like to work on a project where this is unclear.

> Without people willing to contribute their time, open source cannot function.

Agreed, but I would argue that no project, open source or otherwise, can function without contribution guidelines that maintain certain quality standards.

[1]: https://news.ycombinator.com/item?id=39880972

[2]: https://rfc.zeromq.org/spec/42/

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

#657

Post by x-yl »

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…

Can I ask for why it wouldn't have been discovered if the obvious delay wasn't present? Wouldn't anyone profiling a running sshd (which I have to imagine someone out there is doing) see it spending all its crypto time in liblzma?

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

#658

Post by usrusr »

Nathanba wrote: post #394
swid wrote: post #123

Earlier quoted context omitted.

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 understand that we may never see the secret knock but shouldn't we have the door and what's behind it now? Doesn't this mean that the code is quite literally too hard to figure out for a human being? It's not like he can send a full new executable binary that he simply executes, then we'd see that the door is e.g the exec() call. Honestly this attempt makes me think that the entire c/c++ language stack and ecosyste…

The "stuff behind the door" is conveniently uploaded with the secret knock. It's not there and it will never be because it's remotely executed without getting written down. The attacker does send executable code, singed and encrypted (or only one of them? It does not matter) with their private key. The door checks anything incoming for a match with the public key it has and executes when happy.

C++ has nothing to do with this, it's the dynamic linking mechanism that allows trusted code the things it allows trusted code to do (talking about the hooking that makes the key check possible, not about the execution that comes after - that is even more mundane, code can execute code, it's a von Neumann architecture after all).

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

#659

Post by ddalex »

dannyw wrote: post #582
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 ```

That's so strange. This reeks of nation state actors, wanting ways to protect their own systems.

any competent malware dev would have a panic switch...

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

#660

Post by dotancohen »

astrange wrote: post #511
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?

It is possible to prevent libraries from patching functions in other libraries; make those VM regions unwritable, don't let anyone make them writable, and adopt PAC or similar hardware protection so the kernel can't overwrite them either.

That does not sound like the type of machine that I want to work on. I still require a general purpose computer.
Post reply on HN