XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable." • Hacker News Board

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

#701

Post by nullc » Sun, Mar 31, 2024, 1:07 PM UTC

zettabomb wrote: post #685

Nathanba wrote: post #394

Earlier quoted context omitted.

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…

Can we stop the ridiculous C++ fearmongering? You can make vulnerable software in any language, and you can do social engineering on any software.

The people who are busy inserting backdoors in all the "rewrite it in rust" projects where anonymous never heard from before new to programming randos rewrite long trusted high security projects in rust would presumably very much like everyone elses attention directed elsewhere.

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

#702

Post by broadsidepicnic » Sun, Mar 31, 2024, 1:12 PM UTC

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…

Very few if close to zilch companies are using rolling distros in their critical infra.

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

#703

Post by solardev » Sun, Mar 31, 2024, 1:17 PM UTC

hwaccel wrote: post #542

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…

> 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'm a little confused with this recommendation How server is supposed to verify user's password in this case? Store the same hash with exactly the same salt in the database, effectively making the transmitted salted hash a cleartext password?

Yes, the server should never have the cleartext password. In this case the salted hash is the same as a password to you, but it protects users who reuse the same password across different sites. If your entire password DB gets leaked, the attacker would be able to login to your site as your users, but they wouldn't be able to login as those users to other sites without brute forcing all the hashes.

Edit: I guess the reverse is also true, that is, leaked user passwords from other sources can't be easily tested against your user accounts just by sending a bunch of HTTP requests to your server. The attacker would have to at least run the passwords through your particular salted hash scheme first (which they can get by reverse engineering your client, but it's extra labor and computation).

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

#704

Post by solardev » Sun, Mar 31, 2024, 1:19 PM UTC

kortilla wrote: post #583

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…

It doesn’t actually do anything because if SSL is compromised then all of the junk you think you are telling the client to do to the password is via JavaScript that is also compromised. If you’re worried about passive listeners with ssl private keys, perfect forward secrecy at the crypto layer solved that a long time ago. For browsers at least, sending passwords plainly over a tls session is as good as it gets.

It's not to protect against MITM but against credential reuse. It offers no additional security over SSL but what it does protect against is user passwords being leaked and attackers being able to reuse that same password across the user's other online accounts (banks, etc.).

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

#705

Post by ajross » Sun, Mar 31, 2024, 1:21 PM UTC

dotancohen wrote: post #667

ajross wrote: post #172

Earlier quoted context omitted.

Plausibly by having set-user-ID capability but not others an attacker might need. But in the more common case it just doesn't: you have an sshd running on a dedicated port for the sole purpose of running some service or another under a specific sandboxed UID. That's basically the github business model, for example.

I need full filesystem access, VIM, ls, cd, grep, awk, df, du at the very least. Sometimes perl, find, ncdu, and other utilities are necessary as well. Are you suggesting that each tool have its own SSH process wrapping it? Maybe write a shell to coordinate between them? It should support piping and output redirection, please.

Sigh. I'm not saying there's a sandboxed sshd setup that has equivalent functionality to the default one in your distro. I'm not even saying that there's one appropriate for your app.

I'm saying, as a response to the point above, that sandboxing sshd is absolutely a valid defense-in-depth technique for privilege isolation, that it would work against attacks like this one to prevent whole-system exploitation, and that it's very commonly deployed in practice (c.f. running a git/ssh server a-la github).

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

#706

Post by Bnichs » Sun, Mar 31, 2024, 1:21 PM UTC

brcmthrowaway wrote: post #414

So this is why Apple hates open source. Random anons committing to your project.

I think their problem with open source is more that they can't have complete control and make every user's decision for them, security is just a nice tag along to that.

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

#707

Post by matheusmoreira » Sun, Mar 31, 2024, 1:26 PM UTC

nicce wrote: post #689

rubymamis wrote: post #674

It baffles me how such an important package that so many Linux servers use every day is unmaintained by the original author due to insufficient funds. Something gotta change in OSS. I think one solution could be in licenses that force companies/business of certain sizes to pay maintenance fees. One idea from the top of my head.

> I think one solution could be in licenses that force companies/business of certain sizes to pay maintenance fees. One idea from the top of my head. Yet people have huge opposition for those licenses. The big scream of "not free anymore" starts and the entity gets cancelled.

Not really. Just make your software AGPLv3. It's literally the most free license GNU and the FSF have ever come up with. It ensures your freedom so hard the corporations cannot tolerate it. Now you have leverage. If the corporations want it so bad, they can have it. They just gotta ask for permission to use it under different terms. Then they gotta pay for it.

https://www.gnu.org/philosophy/selling-exceptions.html

All you have to do is not MIT or BSD license the software. When you do that, you're essentially transferring your intellectual property to the corporations at zero cost. Can't think of a bigger wealth transfer in history. From well meaning individual programmers and straight to the billionaires.

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

#708

Post by leeoniya » Sun, Mar 31, 2024, 1:37 PM UTC

lodovic wrote: post #681

lazyasciiart wrote: post #631

Earlier quoted context omitted.

How do you mean?

I've read about workplaces that were compromised with multiple people - they would hire a compromised manager, who would then install one or two developers, and shape the environment for them to prevent discovery, which would make these kind of exploits trivial.

so, Office Space?

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

#709

Post by krick » Sun, Mar 31, 2024, 1:40 PM UTC

matheusmoreira wrote: post #707

nicce wrote: post #689

Earlier quoted context omitted.

> I think one solution could be in licenses that force companies/business of certain sizes to pay maintenance fees. One idea from the top of my head. Yet people have huge opposition for those licenses. The big scream of "not free anymore" starts and the entity gets cancelled.

Not really. Just make your software AGPLv3. It's literally the most free license GNU and the FSF have ever come up with. It ensures your freedom so hard the corporations cannot tolerate it. Now you have leverage. If the corporations want it so bad, they can have it. They just gotta ask for permission to use it under different terms. Then they gotta pay for it. https://www.gnu.org/philosophy/selling-exceptions.html Al…

The problem is, there will be almost zero packages that (very few) "corporations want so bad". The only exception might be cloud providers, that want to host your mildly-popular open-source message queue, but, again, if you are Amazon, you'll soon just re-implement that message queue, drop the "original" one, and after a couple of years your mildly-popular project will become not popular at all.

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

#710

Post by kbolino » Sun, Mar 31, 2024, 1:40 PM UTC

kimixa wrote: post #613

semiquaver wrote: post #544

Earlier quoted context omitted.

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

You don't have to have an immutable system.

You can limit the exposure of the system from RCE in sshd with SELinux without preventing legitimate users from administering the system.

Granted that SELinux is overly complicated and has some questionable design decisions from a usability standpoint but it's not as limited or inflexible as many seem to think.

It really can stop a system service running as "root" from doing things a real administrator doesn't want it to do. You can couple it with other mechanisms to achieve defense in depth. While any system is only as strong as its weakest link, you can use SELinux to harden sshd so even with exploits in the wild it's not the weakest link vis-a-vis an attacker getting full unconfined root access. This may or may not be worth your time depending on what that box is doing and how connected to the rest of your infrastructure it is.

There seems to be a pervasive misunderstanding of the difference between standard UNIX/Linux discretionary access control and SELinux-style mandatory access control. The latter cannot be fooled into acting as a confused deputy anywhere near as easily as the former. The quality of the SELinux policy on a particular system plays a big part in how effective it is in practice but a good policy will be far harder to circumvent than anything the conventional permissions model is capable of.

Moreover, while immutability is obviously an even stronger level of protection, it is not necessary to make the system immutable to accomplish what I've described here while still allowing legitimately and separately authenticated users to fully administer the system.