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

691–700 of 862 posts

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

#691

Post by concordDance »

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.

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

Is it actually insufficient funds or is it burnout?

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

#692

Post by nicce »

juliusdavies wrote: post #589

Lucky the XZ license switched from "Public Domain" to 0BSD in February (just before these 5.6.0 and 5.6.1 releases)! 0BSD has no clauses, but it does have this: > IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF O…

But Public Domain license already prevented that? At least in the most countries. But local laws goes above licenses anyway.

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

#693

Post by someguydave »

radiospiel wrote: post #647
kbenson wrote: post #541

Earlier quoted context omitted.

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.

In exchange, each binary can be audited as a final product on its own merits, rather than leaving the final symbols-in-memory open to all kinds of dubious manipulation.

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

#694

Post by rubymamis »

concordDance wrote: post #691
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.

> 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. Is it actually insufficient funds or is it burnout?

I'm not sure. I know from working on OSS projects personally that insufficient funds can easily lead to burnout as well. You gotta find other sources of revenue while STILL maintaining your OSS project.

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

#695

Post by someguydave »

ynik wrote: post #686
Cloudef wrote: post #570

Earlier quoted context omitted.

Not true, it would be much harder to hook into openssl functions if the final executable was static [1], the only way is that if the openssl function this attack targeted, actually called a function from libxz. [1] https://sourceware.org/glibc/wiki/GNU_IFUNC Dynamic loading is relic of the past and cause of many headaches in linux ecosystem, in this case it also just obfuscates the execution path of the code more so…

This particular approach of hooking would be much harder; but a malicious xz has other options as well. It's already in the code path used by dpkg when unpacking packages for security updates, so it could just modify the sshd binary, or maybe add a rootkit to the next kernel security update. It seems foolish to change our systems to stop one of the steps the attacker used after their code was already running as root;…

“It seems foolish to change”

Rejecting evidence in favor of retaining preconceptions is certainly popular.

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

#696

Post by someguydave »

FeepingCreature wrote: post #595
Cloudef wrote: post #570

Earlier quoted context omitted.

Not true, it would be much harder to hook into openssl functions if the final executable was static [1], the only way is that if the openssl function this attack targeted, actually called a function from libxz. [1] https://sourceware.org/glibc/wiki/GNU_IFUNC Dynamic loading is relic of the past and cause of many headaches in linux ecosystem, in this case it also just obfuscates the execution path of the code more so…

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?

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

#697

Post by someguydave »

intelVISA wrote: post #517
someguydave wrote: post #380

Earlier quoted context omitted.

Dynamic linking was a mistake and should be eliminated

yep, but how to reverse such a blunder?

Well step one is to just stop doing it? I guess someone will need to start publishing a static-only linux distro

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

#698

Post by Cloudef »

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?

I mean dynamic loader is part of the base system and you generally trust the compiler and linker you build the program with. If any of those are malicious, you've already lost the game.

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

#699

Post by dingnuts »

concordDance wrote: post #691
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.

> 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. Is it actually insufficient funds or is it burnout?

same thing; if you have money you can hire people to spread the burden

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

#700

Post by treasy »

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 ?

Those files would be editable by something in the sysadm_t domain which is by default the domain of the root user after a successful authentication

This backdoor does not bypass remote authentication so it should be able to transition to the new domain that has access to these files

Post reply on HN