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

751–760 of 862 posts

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

#751

Post by lettergram »

willbush wrote: post #461
lettergram wrote: post #423

Earlier quoted context omitted.

That’s not an explanation about exactly how intention was derived. I suppose I’m asking for the chain of events that led to the conclusion. I see lots of technical hot takes for how something could work, with no validation it does, nor intent behind it. I’d like to understand what steps we know were taken and how that presents itself.

I think you're probably missing a lot context about the situation. Here's some useful links https://x0f.org/@FreePietje/112187047353892463 also https://gynvael.coldwind.pl/?lang=en&id=782

Appreciate, that’s the context I was looking for

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

#752

Post by cryptonector »

yencabulator wrote: post #748
cryptonector wrote: post #321

Earlier quoted context omitted.

I don't understand yet where the "unreplayable" part comes from, but this isn't it.

Replayable: You observe attack against server A, you can take that attack and perform it against server B. This attack is unreplayable because it cryptographically ties into the SSH host key of the server.

I know what replayable means. But even with your explanation of what makes it unreplayable it's not strictly true: you could replay the attack on the server it was originally played against.

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

#753

Post by yencabulator »

cryptonector wrote: post #752
yencabulator wrote: post #748

Earlier quoted context omitted.

Replayable: You observe attack against server A, you can take that attack and perform it against server B. This attack is unreplayable because it cryptographically ties into the SSH host key of the server.

I know what replayable means. But even with your explanation of what makes it unreplayable it's not strictly true: you could replay the attack on the server it was originally played against.

Sure. But the interest is in being able to talk to server B to figure out if it's vulnerable; that's impossible, because the attack can't be replayed to it.

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

#755

Post by db48x »

ynik wrote: post #683
db48x wrote: post #468

Earlier quoted context omitted.

Yes, but don't forget that there are different kinds of sandboxes. SELinux never needs the cooperation of any program running on the system in order to correctly sandbox things. No change to Xz could ever make SELinux less effective.

But don't forget that xz is also used as part of dpkg for unpacking packages. The whole purpose of dpkg is to update critical system packages. Any SELinux policy that protects from a backdoored dpkg/xz installing a rootkit during the next kernel security update; will also prevent installing real kernel security updates. The particular way of attack in this OpenSSH backdoor can maybe be prevented; but we've got to rea…

SELinux policies are much more subtle than that. You don’t restrict what xz or liblzma can do, you restrict what the whole process can do. That process is either sshd or dpkg, and you can give them completely different access to the system, so that if dpkg tries to launch an interactive shell it fails, while sshd fails if it tries to overwrite a system file such as /bin/login or whatever. Neither would ordinarily do that, but the payload delivered via the back door might attempt it and wouldn’t succeed. And you would get a report stating what had happened, so if you’re paying attention the back door starts to become obvious.

Also I think dpkg switched to Zstd, didn’t it? Or am I misremembering?

But you’re not wrong; ultimately both sshd and dpkg are critical infrastructure. SELinux can prevent them from doing completely wrong things, but obviously it wouldn’t be useful for it to prevent them from doing their jobs. And those jobs are security critical already. SELinux is not a panacea, merely defense in depth.

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

#756

Post by godelski »

arter4 wrote: post #635
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…

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 histor…

I think it does make a difference when it comes to vulnerabilities and especially infiltrators. You're doing these things as a hobby. Outside of your real work. If it becomes too big for you it's hard to find help (exact case here). How do you pass on the torch when you want to retire?

I think money can help alleviate pressure from both your points. No one says that money makes them honest. But if it's a full time job you are less likely to just quickly look and say lgtm. You make fewer mistakes when you're less stress or tired. It's harder to be corrupted because people would rather a stable job and career than a one time payout. Pay also makes it easier to trace.

Again, it's not a 100% solution. Nothing will be! But it's hard to argue that this wouldn't alleviate significant pressure.

https://www.mail-archive.com/xz-devel@tukaani.org/msg00567.h...

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

#757

Post by anticristi »

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.

The proposed EU Cyber resilience Act positions itself to be a solution. To put it simply, vendors are responsible for vulnerabilities throughout the lifetime of their products, whether that is a firewall or a toaster. Thus, the vendors are incentives to keep OSS secure, whether that means paying maintainers, commissioning code audits or hiring FTEs to contribute.

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

#758

Post by imiric »

chii wrote: post #735
imiric wrote: post #429

Earlier quoted context omitted.

The late author of ZeroMQ, Pieter Hintjens, advocated for a practice called Optimistic Merging[1], where contributions would be merged immediately, without reviewing the code or waiting for CI results. So your approach of having lax merging guidelines is not far off. While I can see the merits this has in building a community of contributors who are happy to work on a project, I always felt that it opens the project…

> then strange behavior and commits that claim to do one thing but actually do something else, are more likely to be spotted earlier than later. https://en.wikipedia.org/wiki/Underhanded_C_Contest It's actually an art to writing code like that, but it's not impossible and will dodge cursory inspection. And it's possible to have plausible deniability in the way it is constructed.

I'm not sure why my point is not getting across...

I'm not saying that these manual and automated checks make a project impervious to malicious actors. Successful attacks are always a possibility even in the strictest of environments.

What they do provide is a _chance reduction_ of these attacks being successful.

Just like following all the best security practices doesn't produce 100% secure software, neither does following best development practices prevent malicious code from being merged in. But this doesn't mean that it's OK to ignore these practices altogether, as they do have tangible benefits. I argue that projects that have them are better prepared against this type of attack than those that do not.

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

#759

Post by chuckadams »

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 may as well just slap a "no commercial use" restriction on it. It takes months to go through procurement at the average big company, and still would if the package cost $1. Developers at these companies will find something else without the friction.

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

#760

Post by xorcist »

ghostpepper wrote: post #184
joeyh wrote: post #104

Earlier quoted context omitted.

Since a liblzma backdoor could be used to modify compiler packages that are installed on some distributions, it gets right back to a trusting trust attack. Although initial detection via eg strace would be possible, if the backdoor was later removed or went quiescentit would be full trusting trust territory.

How would this be possible? This backdoor works because lzma is loaded into sshd (by a roundabout method involving systemd). I don't think gcc or clang links lzma.

To be fair neither does sshd. But I'm sure someone somewhere has a good reason for gcc to write status via journald or something like that? There's however no reason to limit yourself to gcc for a supply chain attack like this.

In any non trivial build system, there's going to be lots of third party things involved. Especially when you include tests in the build. Is Python invoked somewhere along the build chain? That's like a dozen libraries loaded already.

Nothing is gained from protecting against an exact replica of this attack, but from this family of attacks.

Post reply on HN