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

631–640 of 862 posts

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

#631

Post by lazyasciiart »

rigid wrote: post #627
xlii wrote: post #586

Earlier quoted context omitted.

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…

> it enabled it in the first place it took roughly two years including social engineering. I'd say the same approach is much easier in a big software company.

How do you mean?

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

#633

Post by lazyasciiart »

bandrami wrote: post #526
robocat wrote: post #258

Earlier quoted context omitted.

> we may not have the same luck next time If the prior is 1 was out there (this one), the chances that there is 1+ still undetected seems fairly high to me. To behaviourally detect this requires many independent actors to be looking in independent ways(e.g. security researchers, internal teams). Edit: I mean with private code & tests (not open source, nor purchasable antivirus). It's not easy to donate to Google Zero…

> If the prior is 1 That would surprise me greatly

I think you’re saying “I would be surprised if there is only 1 exploit like this that already exists” which is what the previous comment was also saying. “If the prior is one” is often used to mean “we know for sure that there is one”.

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

#634

Post by mrln »

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…

It's not too hard to figure out. People are figuring it out. If anything is too hard, it's due to obfuscation - not C/C++ shenanigans. As far as I understand from scrolling through these comments, an attacker can send a command that is used with the system() libc call. So the attacker basically has a root shell.

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

#635

Post by arter4 »

godelski wrote: post #476
p-e-w wrote: post #392

Earlier quoted context omitted.

> 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 screwed That's true of course, but it's not a problem specific to software. In fact, I'm not even sure it's a "problem" in a meaningful sense at all. 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. Th…

Honestly this is why I think we should pay people for open source projects. It is a tragedy of the commons issues. All of us benefit a lot from these free software, and done for free. Pay doesn't exactly fix the problems directly, but they do decrease the risk. Pay means people can work on these full time instead of on the side. Pay means it is harder to bribe someone. Pay also makes the people contributing feel bett…

I get why, in principle, we should pay people for open source projects, but I guess it doesn't make much of a difference when it comes to vulnerabilities.

First off, there are a lot of ways to bring someone to "the dark side". Maybe it's blackmail. Maybe it's ideology ("the greater good"). Maybe it's just pumping their ego. Or maybe it's money, but not that much, and extra money can be helpful. There is a long history of people spying against their country or hacking for a variety of reasons, even if they had a job and a steady paycheck. You can't just pay people and expect them to be 100% honest for the rest of their life.

Second, most (known) vulnerabilities are not backdoors. As any software developer knows, it's easy to make mistakes. This also goes for vulnerabilities. Even as a paid software developer, uou can definitely mess up a function (or method) and accidentally introduce an off-by-one vulnerability, or forget to properly validate inputs, or reuse a supposedly one-time cryptographic quantity.

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

#636

Post by xinayder »

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…

> 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 if root login is disabled in sshd config?

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

#637

Post by BbzzbB »

junon wrote: post #275
tootie wrote: post #255

Earlier quoted context omitted.

Mind boggling. How do you even decide what to do with privileges on a billion computers?

There's a reasonably high chance this was to target a specific machine, or perhaps a specific organization's set of machines. After that it could probably be sold off once whatever they were using it for was finished. I doubt we'll ever know the intention unless the ABC's throw us a bone and tell us the results of their investigation (assuming they're not the ones behind it).

ABC?

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

#638

Post by mrln »

snnn wrote: post #127
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…

That's the most interesting part. No, we don't know it yet. The backdoor is so sophisticated that none of us can fully understand it. It is not a “usual” security bug.

What makes you say that? I haven't started reverse engineerinng it myself, but from all I have read, people who did have a very good understanding of what it does. They just can't use it themselves, because they would need to have the attacker's private key.

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

#639

Post by tau255 »

BbzzbB wrote: post #637
junon wrote: post #275

Earlier quoted context omitted.

There's a reasonably high chance this was to target a specific machine, or perhaps a specific organization's set of machines. After that it could probably be sold off once whatever they were using it for was finished. I doubt we'll ever know the intention unless the ABC's throw us a bone and tell us the results of their investigation (assuming they're not the ones behind it).

ABC?

3 letter intelligence agencies.

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

#640

Post by _nalply »

ezekg wrote: post #173
gouggoug wrote: post #160

Earlier quoted context omitted.

For people like me whose C knowledge is poor, can you explain why this dot is significant? What does it do in actuality?

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 is tiny and there are many such tests.

I had a similar problem with unit testing of a library. Expected failures need to be tested as well. As an example imagine writing a matrix inversion library. Then you need to verify that you get something like a division by zero error if you invert the zero matrix. You write a unit test for that and by mistake you insert a syntax error. Then you run the unit test and it fails as expected but not in the correct way.

It's subtle. It fails as expected but it fails because of unexpected wrong causes.

The solution: Check the errors carefully!

Post reply on HN