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

641–650 of 862 posts

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

#641

Post by rigid »

lazyasciiart wrote: post #631
rigid wrote: post #627

Earlier quoted context omitted.

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

I bet in the majority of cases, there's no need to pressure for merging.

In a big company it's much easier to slip it in. Code seemingly less relevant for security is often not reviewed by a lot of people. Also, often people don't really care and just sign it off without a closer look.

And when it's merged, no one will ever look at it again, other than with FOSS.

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

#642

Post by withinboredom »

CanaryLayout wrote: post #450
kbolino wrote: post #337

Earlier quoted context omitted.

I'm assuming SSH root login is disabled and sudo requires separate authentication to elevate, but yeah, if there's a way to elevate yourself to unconfined root trivially after logging in, this doesn't buy you anything. Now, sandboxing sudo (in the general case) with SELinux probably isn't possible.

This does not matter either. The attack came in by loading into systemd via liblzma. It put on a hook and then sits around waiting for sshd to load in so it can learn the symbols then proceeds to swap in the jumps. sshd is a sitting duck. Bifurcating sshd into a multimodule scheme won't work because some part of it still has to be loaded by systemd. This is a web of trust issue. In the .NET world where refection atta…

Do you think state actors won’t just print out random passports?

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

#643

Post by sunshine_reggae »

lll-o-lll wrote: post #395
quatrefoil wrote: post #135

Earlier quoted context omitted.

If the exploit wasn't baing used, the odds would would be pretty low. They picked the right place to bury it (i.e., effectively outside the codebase, where no auditor ever looks). That said, if you're not using it, it defeats the purpose. And the more you're using it, the higher the likelihood you will be detected down the line. Compare to Solarwinds.

> That said, if you're not using it, it defeats the purpose. Not if this was injected by a state actor. My experience with other examples of state actor interference in critical infrastructure, is that the exploit is not used. It’s there as a capability to be leveraged only in the context of military action.

And that leads to the question:

Why do non-friendly state actors (apparently) not detect and eliminate exploits like this one?

Supposedly, they should have the same kind of budgets for code review (or even more, if we combine all budgets of all non-friendly state actors, given the fact that we are talking about open-source code).

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

#644

Post by celdon25 »

beanjuiceII wrote: post #509
godelski wrote: post #476

Earlier quoted context omitted.

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…

Ya so we could have paid this dude to put the exploits in our programs good IDEA y

Using what bank? He used a fake name and a VPN.

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

#645

Post by ddalex »

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

I'd disagree, based on reports of the actor trying to get this upstreamed in Debian and Fedora. Widespread net.

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

#646

Post by az226 »

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?

NSA, CIA, FBI, DHS.

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

#647

Post by radiospiel »

kbenson wrote: post #541
someguydave wrote: post #380

Earlier quoted context omitted.

Dynamic linking was a mistake and should be eliminated

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.

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

even more so: all binaries dynamically linking xz can be updated by installing a fixed library version. For statically linked binaries: not so much, each individual binary would have to be relinked, good luck with that.

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

#648

Post by hosteur »

t0mas88 wrote: post #593
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...

Is Ed448 stronger than Ed25519?

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

#650

Post by shzhdbi09gv8ioi »

CanaryLayout wrote: post #437
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?

any one of us if we sat on the OSSH team would flip the middle finger. What code is the project supposed to write when nothing on main dyn loaded liblzma. It was brought in from a patch they don't have realistic control over. This is a Linux problem, and the problem is systemd, which is who brought the lib into memory and init'd it.

> This is a Linux problem, and the problem is systemd, which is who brought the lib into memory and init'd it.

Not at all, it is a distro issue because a few distros such as Debian chose to patch openssh to bring in systemd support [1].

Other systemd-based distros like Arch Linux remains unaffected because they don't carry this patch.

1: https://sources.debian.org/src/openssh/1%3A9.7p1-2/debian/pa...

Post reply on HN