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

831–840 of 862 posts

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

#831

Post by dvdkon »

versteegen wrote: post #716
dvdkon wrote: post #587

Earlier quoted context omitted.

How about making ssh as secure as (or more secure than) the VPN you'd put it behind? Considering the amount of vulnerabilities in corporate VPNs, I'd even put my money on OpenSSH today. It's not like this is SSH's fault anyway, a supply chain attack could just as well backdoor some Fortinet appliance.

Defence in depth. Which of your layers is "more secure" isn't important if none are "perfectly secure", so having an extra (independent) layer such as a VPN is a very good idea.

You have to decide when to stop stacking, otherwise you'd end up gating access behind multiple VPNs (and actually increasing your susceptibility to hypothetical supply-chain attacks that directly include a RAT).

I'd stop at SSH, since I don't see a conceptual difference to how a VPN handles security (unless you also need to internally expose other ports).

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

#832

Post by mjg59 »

eto-san wrote: post #817
saagarjha wrote: post #496

Earlier quoted context omitted.

No, the problem is that someone had access to backdoor code that runs in a privileged process.

Tell us all, please, how the starting vector of this attack would affect statically compiled dropbear binary even with systemd's libsystemd pwnage? I am very cruious about your reasoning. The fact, that the whole reason this library is even being pulled into the sshd daemon process, is some stupid stuff like readiness notification, which itself is utterly broken on systemd, by design (and thus is forever unfixable),…

The sd-notify protocol is literally "Read socket address from environment variable, write a value to that socket". There's no need to link in libsystemd to achieve this. It's unreasonable to blame systemd for projects that choose to do so. And, in fact, upstream systemd has already changed the behaviour of libsystemd so it only dlopen()s dependencies if the consumer actually calls the relevant entry points - which would render this attack irrelevant.

> Another great spot to break sshd is PAM, which has no place doing there either. Unfortunately it's hard dep. on most linux distros.

There are many things to hate about PAM (it should clearly be a system daemon with all of the modules running out of process), but there's literally no universe where you get to claim that sshd should have nothing to do with PAM - unless you want to plug every single possible authentication mechanism into sshd upstream you're going to end up with something functionally identical.

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

#833

Post by jeroenhd »

hellcow wrote: post #63
jeroenhd wrote: post #12

Earlier quoted context omitted.

> However, since this is an RCE in the context of e.g. an sshd process itself, this means that sshd running as root would allow the payload to itself run as root. With the right sandboxing techniques, SELinux and mitigations could prevent the attacker from doing anything with root permissions. However, applying a sandbox to an SSH daemon effectively is very difficult.

Another reason to adopt OpenBSD style pledge/unveil in Linux.

By design, OpenSSH will start an interactive shell with either the capabilities to escalate to root or direct root permissions. I don't think pledge/unveil will work any better than seccomp already does.

I do like the pledge/unveil API, but I don't think it would've made much of a difference.

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

#834

Post by quotemstr »

LtWorf wrote: post #802
quotemstr wrote: post #239

Earlier quoted context omitted.

Doesn't matter. This is a supply chain attack, not a vulnerability arising from a bug. All sandboxing the certificate parsing code would have done is make the author of the backdoor do a little bit more work to hijack the necessarily un-sandboxed supervisor process. Applying the usual exploit mitigations to supply chain attacks won't do much good. What will? Kill distribution tarballs. Make every binary bit for bit r…

Malware can be in commits as well…

But it's harder to hide there

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

#835

Post by FeepingCreature »

someguydave wrote: post #696
FeepingCreature wrote: post #595

Earlier quoted context omitted.

Looking at IFUNC, there never seems to be a reason to allow function loading from a different library than the one the call is in, right? Maybe a restriction like that could be built in. Or just explicitly enumerate the possible substitutions per site.

Sure, but your solution supposes some kind of linking cop program overseeing the linking process, and who is going to keep the linking cop honest?

Yes, the dynamic linker (/lib/ld-linux.so.2), which is one relatively short program as opposed to thousands of big ones. :)

The point is, there's simply no usecase to require or even allow the program to do IFUNC substitution freely on its own. A programming framework should not opt the developer in to capabilities they don't want or need. Much of C-likes' complexity arises from unnecessary, mandated capabilities.

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

#836

Post by geenat »

Similar exploit vector in Swoole and exactly why it was forked for Open Swoole: https://old.reddit.com/r/PHP/comments/1b9acx3/article_intro_...

Binary blobs under the guise of "testing"- exploit targeting a dependent library.

Thankfully this only effects Swoole users, not all of PHP.

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

#837

Post by Ajedi32 »

matheusmoreira wrote: post #712
sunshine_reggae wrote: post #643

Earlier quoted context omitted.

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

If a government is competent enough to detect this, they're competent enough to add it to their very own cyberweapon stockpile. They wouldn't be able to do that for this particular exploit since it requires successfully decrypting data encrypted by the attacker's secret key. A zero day caused by an accidental bug though? There's no reason for them to eliminate the threat by disclosing it. They can patch their own sys…

> They can patch their own systems

"Their own systems" will necessarily include lots of civilian infrastructure. Hard to make sure all that gets patched without issuing a CVE, let alone without anyone in the general public even being aware of the patch.

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

#838

Post by bdd8f1df777b »

rubymamis wrote: post #736
chii wrote: post #732

Earlier quoted context omitted.

tragedy of the commons. If someone else can pay to maintain it, but you get the benefits, then it's the obvious strategy to use. And also, there's zero evidence that proprietary software won't have these backdoors. In fact, you can't even check them for it!

That's why I think such OSS packages should use licenses that force large companies to pay (moderate) fees for maintenance. I assume such sums of money won't even tickle them. Imagine 10 large companies, each pay $1000 a month for critical packages they use. For each developer, that's $10,000 they can either use to quit their current job or hire another person to share the burden. We need to normalize this.

You are conflating convenience with necessity. Currently large companies also use xz simply because it is configured to be the default in many distributions. If it charges them money, they will just move to zstd, brottoli, gzip or 7z. The first two are backed by large companies themselves who will not adopt these kind of licenses ever.

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

#839

Post by ahmedtd »

solardev wrote: post #465
cayde wrote: post #401

Earlier quoted context omitted.

No, usually it's sent in plain text to the server, however encapsulated.

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 that work like this --- PAKEs like Secure Remote Passwords: https://www.ietf.org/rfc/rfc2945.txt

They have low uptake because they don't really offer any security beyond just sending the plaintext password over a properly-functioning TLS channel.

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

#840

Post by tialaramex »

djao wrote: post #742
someplaceguy wrote: post #513

Earlier quoted context omitted.

> if you're using password auth, and you are tricked into connecting to a malicious server, that server now has your plaintext password and can impersonate you to other servers. Why would the password be sent in plaintext instead of, say, sending a hash of the password calculated with a salt that is unique per SSH server? Or something even more cryptographically sound. In fact, passwords in /etc/shadow already do hav…

It's a little bit more complicated than just sending a hash of the password, but there are ways to authenticate using hashed passwords without sending the password over the wire, for example https://en.wikipedia.org/wiki/Digest_access_authentication or https://en.wikipedia.org/wiki/Password-authenticated_key_agr... Even so, these protocols require the server to know your actual password, not just a hash of the passwo…

Asymmetric PAKEs don't require the server to know your password. You and the server need to have a discussion to establish some parameters that work for your chosen password, without revealing what it is, and then in future you can supply evidence that you indeed know the password (that is, some value which satisfies the agreed parameters), still without revealing what it is. This is not easy to do correctly, whereas it's really easy to get it wrong...

https://datatracker.ietf.org/doc/draft-irtf-cfrg-opaque/

Post reply on HN