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

761–770 of 862 posts

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

#761

Post by d-z-m »

hosteur wrote: post #648
t0mas88 wrote: post #593

Earlier quoted context omitted.

Maybe their organisation has a policy that requires stronger encryption? Possibly because that organisation is also in the business of cracking such encryption...

Is Ed448 stronger than Ed25519?

Quantitatively, yes(2^224 security target vs 2^128 security target respectively wrt. discrete log calculation).

Qualitatively, 2^128 is already computationally infeasible(barring some advance in quantum computing), so the meaningful difference in security is debatable, assuming no weaknesses in the underlying curve.

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

#762

Post by someguydave »

Cloudef wrote: post #698
someguydave wrote: post #696

Earlier quoted context omitted.

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.

Asking a programmer to trust his own compiler and libraries which he can personally analyze and vouch for (static linking) is much different than asking the programmer to vouch for the dynamic libraries present on some given user’s machine.

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

#763

Post by Aquilla_ »

Muromec wrote: post #146
dolmen wrote: post #132

Earlier quoted context omitted.

I can't blame anyone who has missed that dot dissimulated at the beginning of the line. https://git.tukaani.org/?p=xz.git;a=commitdiff;h=f9cf4c05edd...

I specifically opened this diff to search for a sneaky dot, knowing it’s there, and wasn’t able to find it until I checked the revert patch

Same, I knew a sneaky dot was in the diff but had to ctrl-f the diff to find it.

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

#764

Post by astrange »

dotancohen wrote: post #660
astrange wrote: post #511

Earlier quoted context omitted.

It is possible to prevent libraries from patching functions in other libraries; make those VM regions unwritable, don't let anyone make them writable, and adopt PAC or similar hardware protection so the kernel can't overwrite them either.

That does not sound like the type of machine that I want to work on. I still require a general purpose computer.

Why does a general purpose computer need to overwrite crypto functions in sshd?

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

#765

Post by xorcist »

x-yl wrote: post #657
sega_sai wrote: post #95

One have question on this is, if the backdoor would not been discovered due to performance issue (which was as I understood it purely an oversight/fixable deficiency in the code), what are the chances of discovering this backdoor later, or are there tools that would have picked it up? Those questions are IMO relevant to understand if this kind of backdoor is the first one of the kind, or the first one that was uncove…

Can I ask for why it wouldn't have been discovered if the obvious delay wasn't present? Wouldn't anyone profiling a running sshd (which I have to imagine someone out there is doing) see it spending all its crypto time in liblzma?

The situation certainly wouldn't be helped by the fact that this exploit targeted the systemd integration used by Debian and Red Hat. OpenSSH developers aren't likely to run that since they already rejected that patch for the increased attack surface. Hard to argue against, in retrospect. The attack also avoids activation under those conditions a profiler or debugger would run under.

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

#766

Post by rubymamis »

chuckadams wrote: post #759
rubymamis wrote: post #736

Earlier quoted context omitted.

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.

Maybe we need a platform to make this easier?

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

#767

Post by nicce »

matheusmoreira wrote: post #728
krick wrote: post #709

Earlier quoted context omitted.

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.

In that case we'll simply end up exactly where we started. There's a twist though. This time around we're not being taken for fools and exploited. Better to have a completely irrelevant forgotten project than a massively popular one that makes us zero dollars while CEOs make billions off of it. This post always comes to mind every time this topic comes up: https://web.archive.org/web/20120620103603/http://zedshaw.co.…

That is a really good post from 15? years ago, and still very relevant to this day.

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

#768

Post by d-z-m »

supposemaybe wrote: post #388
circusfly wrote: post #385

Could the backdoor have targeted Wireguard instead of ssh?

Ssh is shell, whereas wireguard is a vpn. You will still be vulnerable as you can connect to an ssh server through your wireguard tunnel.

I don't think that's what OP is asking. I think OP is asking if wireguard functions could be hooked in the same way as sshd functions are in this exploit.

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

#769

Post by d-z-m »

circusfly wrote: post #385

Could the backdoor have targeted Wireguard instead of ssh?

My first instinct would be no, as wireguard runs in kernel space(if you're using kernel wireguard, not wireguard-go/some other userspace implementation),and couldn't link in liblzma, a userspace component.

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

#770

Post by nicce »

rubymamis wrote: post #766
chuckadams wrote: post #759

Earlier quoted context omitted.

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.

Maybe we need a platform to make this easier?

There is already GitHub Sponsors, for example. What we need to change from that?
Post reply on HN