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

611–620 of 862 posts

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

#611

Post by Klonoar »

supposemaybe wrote: post #387
lyu07282 wrote: post #365

God the amount of damage this would've caused, nightmarish, we are so unbelievably lucky. In a few months it would've been in every deb&rpm distribution. Thank God we found it early!

Found it early?.. I found the backdoor on five of my Vultr servers as well as my MacBook Pro this evening. I certainly didn’t catch it early. So if that’s the state of it, it could very well be too late for many many companies. Not to mention folks who rely on TOR for their safety - there could be entire chains of backdoored entry, middle and exit nodes exposing vast numbers of TOR users over the past month or so (sp…

...maybe list the distros or macOS point releases/paths that you found it on macOS. ;P

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

#612

Post by sitkack »

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.

You would have to agree that it was possible for the government to break the law. And what the repercussions are when that happens.

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

#613

Post by kimixa »

semiquaver wrote: post #544
treasy wrote: post #328

Earlier quoted context omitted.

Selinux domains are uncoupled from Linux users. If sshd does not have Selinux permissions to edit those files it will simply be denied. Even if sshd is run as root

Which amounts to the un-administerable system I mentioned. If it’s not possible to modify systemd config files using ssh, what happens when you need to edit them ?

Really what they're proposing here is a non-modifiable system, where the root is read-only and no user can modify anything important.

Which is nice and all, but that implies a "parent" system that creates and deploys those systems. Which people likely want remote access to.. Probably by sshd...

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

#614

Post by adtac »

rany_ wrote: post #608
adtac wrote: post #560

Earlier quoted context omitted.

It will still work if the connecting client offers a RSA key. The only real way to be sure it's not on your system is if your liblzma version is strictly less than 5.6.0 (first infected version): ls -al $(ldd $(which sshd) | grep lzma | awk '{ print $3 }')

Thanks for the reply, I was just curious because `RSA_public_decrypt` threw me off.

FWIW RSA_public_decrypt is an 90s way of saying RSA_signature_validate

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

#615

Post by LtWorf »

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…

Anons will just steal identities, and randos will get accused of hacking they didn't do.

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

#616

Post by ykonstant »

1oooqooq wrote: post #547
dmonitor wrote: post #342

Earlier quoted context omitted.

I’m confused. I make a unique private key for each machine I use. How is using that machine-specific key on multiple hosts insecure?

edit your .ssh/config. add one Host entry per domain. on the end of the file add one catch all host rule with IdentityFile /dev/null otherwise you're sending default key names to all hosts. ...and you are not sending id_rsa.pub to every single place you add a key, like most guides suggests, right? right?

I would be interested in a comprehensive guide on "doing it right", or a link to a guide that suggests the right thing.

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

#617

Post by guenthert »

londons_explore wrote: post #250
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.

I suspect I could have used this exact attack against 10,000 random SSH servers spread all over the world, and not be detected. Most people don't log TCP connections, and those that do don't go through their logs looking for odd certificates in ssh connections. And no common logging at the ssh/pam level would have picked this up. Your only chance is some sysadmin who has put 'tripwires' on certain syscalls like syste…

There are those who run sshd on a non-standard port and log all attempts to connect to the standard port though.

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

#618

Post by kimixa »

webmaven wrote: post #539
rcxdude wrote: post #336

Earlier quoted context omitted.

This is full conspiracy mode thinking.

Yes, well, there actually was a conspiracy here, wasn't there? The only question is how extensive it was in time and space.

I wonder if the fact they "had" to use a dependency and jump through a number of hoops suggest they're not involved in the conspiracy? As if they had this sort of access and effort surely systemd itself would be an easier target?

But that's not saying this is the only conspiracy, maybe there's hundreds of other similar things in published code right now, and one was noticed soon after introduction merely due to luck.

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

#619

Post by everybackdoor »

snnn wrote: post #338
EasyMark wrote: post #279

Earlier quoted context omitted.

don't most people who use that just use it for scanning incoming email attachments usually?

ClamAV also has a lot of findings when scanning some open source project's source code. For example, LLVM project's test data. Because some of the test data are meant to check if a known security bug is fixed, from a antivirus software perspective these data files can be seen as exploits. ClamAV is commonly used. Or, I would suggest adding it to every CI build pipeline. Most time it wouldn't have any finding, but it…

[dead]

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

#620

Post by [deleted] »

ikekkdcjkfke wrote: post #418
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…

[flagged]

[deleted]
Post reply on HN