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

801–810 of 862 posts

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

#801

Post by kbenson »

Dalewyn wrote: post #569
kbenson wrote: post #556

Earlier quoted context omitted.

> Even Americans usually don't drink that hard; the French earned my respect that day. Is drinking hard something so deserving of respect? Is working while impaired? To me this reads as "I like to fuck off and be irresponsible and man did these French guys show me how it's done!"

Except they weren't irresponsible. We all drove back just fine, and we all went back to work just as competently as before like nothing happened. It takes skill and maturity to have a good time but not so much that it would impair subsequent duties. The French demonstrated to me they have that down to a much finer degree than most of us have in America, so they have my respect. This isn't to say Americans are immatur…

One of the well known effects of alcohol is impaired judgment. You're expecting people with some level of impaired judgment to make correct judgment calls. Skill and maturity can help, but are not a solution to that fundamental problem.

Would you be okay with a surgeon operating on you in the afternoon drinking at lunch and working on you later while impaired? Is it okay for every person and job to be impaired, regardless of the responsibility of their situation? If not, why is operating a few thousand pound vehicle in public that can easily kill multiple people when used incorrectly okay?

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

#802

Post by LtWorf »

quotemstr wrote: post #239
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.

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…

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

#803

Post by b112 »

streb-lo wrote: post #794
b112 wrote: post #776

Earlier quoted context omitted.

Yet Redhat and others applied this patch, as systemd is so incapable of reliably launching processes, that it kept killing sshd without it. What a complete failure of an init system's job, and the patch was applied due to systemd not resolving the issue in another way. This is the problem with systemd. Way, way way too much complexity.

systemd is just fine on Arch without this patch. It's not a systemd issue, it's a larger cultural issue with packagers increasing attack surface to make their lives easier.

It absolutely, positively, 100% was added due to issues with systemd.

Both Redhat and Debian and others applied this patch as a result. People didn't do it "just cause".

https://bugzilla.redhat.com/show_bug.cgi?id=1381997

Jakub Jelen 2016-10-12 08:40:44 UTC

> Why do you want to avoid sd_notify()?

Why to avoid this? Well, it is adding more systemd-specific bits and new build dependency to something that always worked well under other inits without any problems for years.

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

#804

Post by rwmj »

astrange wrote: post #800
rwmj wrote: post #796

Earlier quoted context omitted.

They're all in a single address space, there's nothing you can do to stop one part of a binary patching any other part.

I already said the way to do it in my previous comment. Don't let arbitrary code run before page permissions are locked down.

If you're running in the binary you can call mprotect(2), and even if that is blocked you can cause all kinds of mischief. The original motivation for rings of protection on i286 was so that libraries could run in a different ring from the binary (usually library in ring 2 and program in ring 3), using a call gate (a very controlled type of call) to dispatch calls from the binary to the library, which stops the binary from modifying the library and IIRC libraries from touching each other. But x86-64 got rid of the middle rings.

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

#805

Post by LtWorf »

someguydave wrote: post #697
intelVISA wrote: post #517

Earlier quoted context omitted.

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

I think you don't fully understand how the attack works.

Had sshd been written in go or rust, the attack would have still been possible.

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

#806

Post by asveikau »

b112 wrote: post #776
shzhdbi09gv8ioi wrote: post #650

Earlier quoted context omitted.

> This is a Linux problem, and the problem is systemd, which is who brought the lib into memory and init'd it. Not at all, it is a distro issue because a few distros such as Debian chose to patch openssh to bring in systemd support [1]. Other systemd-based distros like Arch Linux remains unaffected because they don't carry this patch. 1: https://sources.debian.org/src/openssh/1%3A9.7p1-2/debian/pa...

Yet Redhat and others applied this patch, as systemd is so incapable of reliably launching processes, that it kept killing sshd without it. What a complete failure of an init system's job, and the patch was applied due to systemd not resolving the issue in another way. This is the problem with systemd. Way, way way too much complexity.

I think the criticisms of systemd are valid but also tangential. I think Poettering himself is on one of the HN threads saying they didn't need to link to his library to accomplish what they sought to do. Lzma is also linked into a bunch of other critical stuff, including but not limited to distro package managers and the kernel itself, so if they didn't have sshd to compromise, they could have chosen another target.

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

#807

Post by b112 »

asveikau wrote: post #806
b112 wrote: post #776

Earlier quoted context omitted.

Yet Redhat and others applied this patch, as systemd is so incapable of reliably launching processes, that it kept killing sshd without it. What a complete failure of an init system's job, and the patch was applied due to systemd not resolving the issue in another way. This is the problem with systemd. Way, way way too much complexity.

I think the criticisms of systemd are valid but also tangential. I think Poettering himself is on one of the HN threads saying they didn't need to link to his library to accomplish what they sought to do. Lzma is also linked into a bunch of other critical stuff, including but not limited to distro package managers and the kernel itself, so if they didn't have sshd to compromise, they could have chosen another target.

And yet:

https://news.ycombinator.com/item?id=39878181

So no, as Pottering claimed, sshd would not be hit by this bug except for this systemd integration.

I really don't care about "Oh, someone could have written another compromise!". What allowed for this compromise, was a direct inability for systemd to reliable do its job as an init system, necessitating a patch.

And Redhat, Fedora, Debian, Ubuntu, and endless other distros took this route, because something was required, and here we are. Something that would not be required if systemd could actually perform its job as an init system without endless work arounds.

Also see my other reply in this thread, re Redhat's patch.

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

#808

Post by asveikau »

b112 wrote: post #807
asveikau wrote: post #806

Earlier quoted context omitted.

I think the criticisms of systemd are valid but also tangential. I think Poettering himself is on one of the HN threads saying they didn't need to link to his library to accomplish what they sought to do. Lzma is also linked into a bunch of other critical stuff, including but not limited to distro package managers and the kernel itself, so if they didn't have sshd to compromise, they could have chosen another target.

And yet: https://news.ycombinator.com/item?id=39878181 So no, as Pottering claimed, sshd would not be hit by this bug except for this systemd integration. I really don't care about "Oh, someone could have written another compromise!". What allowed for this compromise, was a direct inability for systemd to reliable do its job as an init system, necessitating a patch. And Redhat, Fedora, Debian, Ubuntu, and endless oth…

I'm not the type to go out of my way to defend systemd and their design choices. I'm just saying the severity of this scenario of a tainted library transcends some of the legit design criticisms. If you can trojan liblzma you can probably do some serious damage without systemd or sshd.

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

#809

Post by b112 »

asveikau wrote: post #808
b112 wrote: post #807

Earlier quoted context omitted.

And yet: https://news.ycombinator.com/item?id=39878181 So no, as Pottering claimed, sshd would not be hit by this bug except for this systemd integration. I really don't care about "Oh, someone could have written another compromise!". What allowed for this compromise, was a direct inability for systemd to reliable do its job as an init system, necessitating a patch. And Redhat, Fedora, Debian, Ubuntu, and endless oth…

I'm not the type to go out of my way to defend systemd and their design choices. I'm just saying the severity of this scenario of a tainted library transcends some of the legit design criticisms. If you can trojan liblzma you can probably do some serious damage without systemd or sshd.

Of course you can trojan other ways, but that can only be said, in this thread, in defense of systemd.

After all, what you're saying is and has always been the case! It's like saying "Well, Ford had a design flaw in this Pinto, and sure 20 people died, but... like, cars have design flaws from time to time, so an accident like this would've happened eventually anyhow! Oh well!"

It doesn't jive in this context.

Directly speaking to this point, patched ssh was chosen for a reason. It was the lowest hanging fruit, with the greatest reward. Your speculation about other targets isn't unwarranted, but at the same time, entirely unvalidated.

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

#810

Post by astrange »

rwmj wrote: post #804
astrange wrote: post #800

Earlier quoted context omitted.

I already said the way to do it in my previous comment. Don't let arbitrary code run before page permissions are locked down.

If you're running in the binary you can call mprotect(2), and even if that is blocked you can cause all kinds of mischief. The original motivation for rings of protection on i286 was so that libraries could run in a different ring from the binary (usually library in ring 2 and program in ring 3), using a call gate (a very controlled type of call) to dispatch calls from the binary to the library, which stops the binar…

> If you're running in the binary you can call mprotect(2)

Darwin doesn't let you make library regions writable after dyld is finished with them. (Especially iOS where codesigning also prevents almost all other ways to get around this.)

Something like OpenBSD pledge() can also revoke access to it in general.

> But x86-64 got rid of the middle rings.

x86 is a particularly insecure architecture but there's no need for things to be that way. That's why I mentioned PAC, which prevents other processes (including the kernel) from forging pointers even if they can write to another process's memory.

Post reply on HN