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

841–850 of 862 posts

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

#841

Post by MuffinFlavored »

skywhopper wrote: post #128
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…

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…

> 2. The XZ library injects its own versions of functions in openssl that verify RSA signatures

Specifically how did the xz library patch/hook/inject into the openssl functions that verify RSA signatures?

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

#842

Post by solardev »

ahmedtd wrote: post #839
solardev wrote: post #465

Earlier quoted context omitted.

Wow, really? Ten years ago, it was drilled into me to never send a password like that, especially since the server shouldn't have the plain version anyway (so no reason for the client to send it). https://owasp.org/www-community/OWASP_Application_Security_F... says "Salted hash for transmitting passwords is a good technique. This ensures that the password can not be stolen even if the SSL key is broken." I didn't wan…

That page seems to be a community wiki, and I think the original authors are somewhat confused on that point. If you salt and hash the password on the client side, how is the server going to verify the password. Everything I can think of either requires the server to store the plaintext password (bad) or basically makes the hashed bytes become the plaintext password (pointless). There are password-based solutions tha…

Good catch on the wiki authors.

But I think the point of salting + hashing the password isn't quite the same as what TLS offers. It's not necessarily to prevent MITM eavesdropping, but to help protect the user from credential re-use from leaks.

What was I taught is that your server should never have the user's cleartext password to begin with, only the salted hash. As soon as they set it, the server only ever gets (and saves) the salted hash. That way, in the worst case scenario (data leak or rogue employee), at most your users would only have their accounts with you compromised. The salted hashes are useless anywhere else (barring quantum decryption). To you they're password equivalents, but they turn the user's weak reused password (that they may be using for banking, taxes, etc.) into a strong salted hash that's useless anywhere else.

That's the benefit of doing it serverside, at least.

Doing it clientside, too, means that the password itself is also never sent over the wire, just the salted hash (which is all the server needs, anyway), limiting the collateral damage if it IS intercepted in transit. But with widespread HTTPS, that's probably not a huge concern. I do think it can help prevent accidental leaks, like if your auth endpoint was accidentally misconfigured and caching or logging requests with cleartext passwords... again, just to protect the user from leaks.

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

#843

Post by tonymet »

tonymet wrote: post #754

Who was the author ?

A subsequent investigation found that the backdoor was a culmination of approximately 3 years of effort by a user going by the name Jia Tan and the nickname JiaT75, who appears to have made a concentrated effort to gain access to a position of trust within the xz project, by putting pressure on the head maintainer to step down and hand over the control of the project.[3]

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

#844

Post by saagarjha »

int_19h wrote: post #813
saagarjha wrote: post #520

Earlier quoted context omitted.

All of this was obfuscated. None of this will be detectable with current static analysis techniques.

We have governments, which even in the face of budget crises and such tend to allocate enormous sums for "national security". Why not have them actually do something useful with that for once and do a manual line-by-line audit of all security-critical code that is underpinning our infrastructure?

They do this, but probably not as much as they should.

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

#845

Post by saagarjha »

josephg wrote: post #815
saagarjha wrote: post #791

Earlier quoted context omitted.

Yes but that requires you to know that someone will use it beforehand.

Now that we know IFUNC can me misused like this, it would be pretty silly if we allow other, future exploits to use the same trick.

ifunc was only used because it’s an obscure feature that is little-used and provides a way to convert a backdoor into easy execution. There are many others and it would be silly to try to catch them all.

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

#846

Post by saagarjha »

wepple wrote: post #820
saagarjha wrote: post #507

Earlier quoted context omitted.

This is an arms race that is largely won by attackers, actually. Sophisticated attacks are caught by them sometimes but usually the author has far more knowledge or cleverer tricks than the person implementing the checks, who is limited by their imagination of what they think an attacker might do.

I’m not sure that attackers “win” this arms race; the cost has gone through the roof and their chance of detection constantly increases. Indeed, defenders are often outgunned, but at a minimum we’ve pushed the level of effort way into nation-state territory, which is a good start.

Indeed. But a lot of the effort has come from measures in areas that are much more stacked towards defenders (as it should).

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

#847

Post by timattrn »

xlii wrote: post #586
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…

Working for about a year in an environment that was exposed to high volume of malevolent IT actors (and some pretty scary ones) I’d say: discovery chances very always pretty high. Keeping veil of secrecy requires unimaginable amount of energy. Same goes with truth consistency. One little slip and everything goes to nothing. Sometimes single sentence can start a chain of reaction and uncover meticulous crafted plan. T…

Another independent maintainer would have helped too. Many eyes make bugs shallow, but just one extra genuine maintainer would have helped enormously. Clearly the existing maintainer trusted the attacker completely, but a second maintainer would not have. That's another social dimension to this attack: doing enough real work to suppress other maintainers coming along.

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

#848

Post by brokenmachine »

tempay wrote: post #771
guenthert wrote: post #727

Earlier quoted context omitted.

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?

It’s more analogous to getting hired at the lock company and sabotaging the locks you assemble to be trivially pickible if you know the right trick. The University of Minnesota case is an interesting one to compare to. I could imagine them being criminally liable but being given a lenient punishment. I wonder if the law will end up being amended to better cover this, if it isn’t already explicitly illegal.

What happened at the University of Minnesota?

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

#849

Post by brokenmachine »

londons_explore wrote: post #266
wepple wrote: post #99

Earlier quoted context omitted.

I expect a lot of people will be doing a whole lot of thinking along these lines over the next months. Code review? Some kind of behavioral analysis? IMO the call to system() was kind of sloppy, and a binary capabilities scanner could have potentially identified a path to that.

I'm really surprised they did a call to system() rather than just implement a tiny bytecode interpreter. A bytecode interpreter that can call syscalls can be just a few hundred bytes of code, and means you can avoid calling system() (whose calls might be logged), and avoid calling mprotect to make code executable (also something likely to raise security red flags). The only downside of a bytecode interpreter is the w…

XZ backdoor v2.0 is sure to have that now.

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

#850

Post by x0x0 »

raggi wrote: post #198
Denvercoder9 wrote: post #190

Earlier quoted context omitted.

> - current systemd versions already remove liblzma from their dependencies, the affected distros are behind on systemd updates though The affected distros aren't behind on systemd updates, the change to systemd you describe has been merged but not yet released.

Ah, thank you for the correction!

Maybe you should reconsider your "blind belief mud slinging" eh?

Be better.

Post reply on HN