Live data from Hacker News

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

bsky.app

771–780 of 862 posts

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

#771

Earlier quoted context omitted.

That's like asking if someone that went into a crowded place with a full-automatic and started shooting at people but "purposefully missing" is just testing how fast law enforcement reacts, you know, for science. After something like 2 years of planning this out and targeted changes this isn't something "just done for science".

Or is it rather like someone posting a video on youtube on how to pick a common lock? And what's about the fellows of U of Minnesota?

It’s more analogous to getting hired at the lock company and sabotaging the locks you assemble to be trivially pickible if you know the right trick.

The University of Minnesota case is an interesting one to compare to. I could imagine them being criminally liable but being given a lenient punishment. I wonder if the law will end up being amended to better cover this, if it isn’t already explicitly illegal.

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

#772
post #64

Earlier quoted context omitted.

Is it illegal to distribute malware? I see security researchers doing it all the time for analysis purposes.

No, it is not illegal to distribute malware by itself, but it is illegal to trick people into installing malware. The latter was the goal of the XZ contributor.

I would somewhat agree, but then come to mind "what is the "legal" definition of malware ?".

Some people would say that most drm software would act like malware/ransomware.

And tricking people to install such software is only matter of an ambiguously worded checkbox.

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

#773
post #770

Earlier quoted context omitted.

Maybe we need a platform to make this easier?

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

I’m not an expert on this. if it ticks all the legal and other issues big companies need to deal with in a frictionless manner, then that’s good. If not, maybe a different solution is needed.

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

#774
post #582

There appears to be a string encoded in the binary payload: https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01... Which functions as a killswitch: https://piaille.fr/@zeno/112185928685603910 If that is indeed the case, one mitigation might be ``` echo "yolAbejyiejuvnup=Evjtgvsh5okmkAvj" | sudo tee -a /etc/environment ```

That's so strange. This reeks of nation state actors, wanting ways to protect their own systems.

This is a good example of bad logic. It doesn't reek of anything except high quality work. You have an unacknowledged assumption that only nation state actors are capable of high quality work. I think that ultimately you want it to be nation state actors and therefore you see something that a nation state actor would do, so you backtrack that it is a nation state actor. So logically your confirmation bias leads you to affirm the consequent.

I only say this because I'm tired of seeing the brazen assertions of how this has to be nation state hackers. It is alluring to have identified a secret underlying common knowledge. Thats why flat-earthers believe theyve uncovered their secret, or chem trail believers have identified that secret, or vaxxers have uncovered the secret which underlies vaccines. But the proof just isn't there. Dont fall into the trap they fell into.

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

#775

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.

There's a difference between important and necessary. The package is necessary not important.

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

#776

Earlier quoted context omitted.

any one of us if we sat on the OSSH team would flip the middle finger. What code is the project supposed to write when nothing on main dyn loaded liblzma. It was brought in from a patch they don't have realistic control over. This is a Linux problem, and the problem is systemd, which is who brought the lib into memory and init'd it.

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

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

#777
post #671

Earlier quoted context omitted.

To me it seems too clumsy to be USG. They seem to prefer back doors that are undetectable or hide in plain sight. But it might be an NSA op designed to instigate a much needed serious examination of the supply chain.

That would honestly be one of the most impactful bits of public service to fall out of any agency, regardless of country. Even if this is nefarious, a couple of intentionally clumsy follow-ups designed to draw further attention would be amazing to see. Think chaos monkey for software supply chain.

Can the community aspects of FOSS survive a Spy vs Spy environment though?

I don't know, but the answer is irrelevant to whether we are in one (we are).

I shudder to think what lurks in the not-open-source world. Closed source software/firmware/microcode, closed spec/design hardware; and artificial restriction of device owners from creating replacement code, or modifying code in consumer and capital goods containing universal machines as components; are significant national security threats and the practice of keeping design internals and intent secret in these products produces a cost on society.

I propose that products which don't adhere to GNU-like standards of openness (caveat*) get national sales taxed some punitive obscene percentage, like 100%. This way the government creates an artificial condition which forces companies to comply lest their market pricing power be absolutely hobbled. If say your company makes five $10MM industrial machines for MEGACORP customer and you're the only game in town, MEGACORP can pay the sales tax. Brian, Dale, and Joe Sixpack can't afford $2,500+ iPhones and Playstations, or $70,000 base model Honda Civics (yes this should apply to cars and especially medical devices/prosthetics), so when Company B comes around making a somewhat inferior competing fully open product then Company A making the proprietary version loses a huge chunk of market share.

(*But not the GNU-spirit distribution rights, so the OEM or vendor is still the only entity legally allowed to distribute [except for national emergency level patches]. Patent rights still apply.)

This is the most direct and sane way to address the coming waves of decade+ old lightbulbs and flatscreens. It has fewest "But if" gotcha exceptions with which to keep screwing you. Stop sticking up for your boss and think about the lack of access to your own devices, or better yet the implicit and nonconsensual perpetual access vendors maintain to universal machines which by all rights only you should have sovereign control over (like cooking your own microcode or tweaking Intel's [but not distributing your tweaks to Intel's])!

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

#778
post #375

Earlier quoted context omitted.

I’m confused. I make a unique private key for each machine I use. How is using that machine-specific key on multiple hosts insecure?

Your SSH public keys used on GitHub are very publicly exposed. This information could be used by SSH servers you are connecting to. You might think you are connecting anonymously, while in fact your SSH client is sending your public key which could then be resolved to your GitHub account.

I don't get it. How do you end up with shell access on a machine you don't trust to know your identity?

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

#779
post #767

Earlier quoted context omitted.

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.

Yeah, I've never forgotten it.

He hasn't stopped blogging either.

https://zedshaw.com/blog/2022-02-05-the-beggar-barons/

https://zedshaw.com/blog/2018-03-25-the-billionaires-vs-bran...

That last link is about this place and covers some abuse he got here on HN over that GPL article. All the way back from 2009.

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

#780

Earlier quoted context omitted.

I suspect I could have used this exact attack against 10,000 random SSH servers spread all over the world, and not be detected. Most people don't log TCP connections, and those that do don't go through their logs looking for odd certificates in ssh connections. And no common logging at the ssh/pam level would have picked this up. Your only chance is some sysadmin who has put 'tripwires' on certain syscalls like syste…

There are those who run sshd on a non-standard port and log all attempts to connect to the standard port though.

Those connection attempts wouldn't ever reach the daemon though, let alone get to preauth. So how would an exploitation attempt even be distinguishable from, say, a harmless random password guess if neither ever gets to see the daemon?
Post reply on HN