Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Backdoor in upstream xz/liblzma leading to SSH server compromise

openwall.com

Post reply on HN
Print view View original

611–620 of 1001 posts

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#611

Post by fwungy »

Brain fart: would it be possible to attach passwords to a crypto based micro transaction such that every time you attempted a password entry your crypto account was charged a small fee for the login attempt?

This would thwart brute force attacks, but not be a significant cost for users. If you could attach your login to the crypto account it would mean the account would have to be funded to allow the attempt. The token wouldn't store passwords it would just be a gatekeeper to the login attempt.

The fees would be paid to the service providers as mining fees.

E.g. foo@bar.com needs a password and a token provided from a designated crypto address to gain access to the service.

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#612

Post by SoftTalker »

api wrote: post #475
rwmj wrote: post #42

Very annoying - the apparent author of the backdoor was in communication with me over several weeks trying to get xz 5.6.x added to Fedora 40 & 41 because of it's "great new features". We even worked with him to fix the valgrind issue (which it turns out now was caused by the backdoor he had added). We had to race last night to fix the problem after an inadvertent break of the embargo. He has been part of the xz proj…

I’m surprised there isn’t way more of this stuff. The supply chain is so huge and therefore represents so much surface area.

There probably is. Way more than anyone knows. I bet every major project on github is riddled with state actors.

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#614

Post by WatchDog »

ptx wrote: post #168
arp242 wrote: post #47

I've long since said that if you want to hide something nefarious you'd do that in the GNU autoconf soup (and not in "curl | sh" scripts). Would be interesting to see what's going on here; the person who did the releases has done previous releases too (are they affected?) And has commits going back to 2022 – relatively recent, but not that recent. Many are real commits with real changes, and they have commits on some…

Couldn't the autoconf soup be generated from simpler inputs by the CI/CD system to avoid this kind of problem? Incomprehensible soup as a build artifact (e.g. executables) is perfectly normal, but it seems to me that such things don't belong in the source code. (This means you too, gradle-wrapper! And your generated wrapper for your generated wrapper. That junk is not source code and doesn't belong in the repo.)

gradle-wrapper is just a convenience, you can always just build the project with an installed version of gradle. Although I get your point, it’s a great place to hide nefarious code.

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#616

Post by Bulat_Ziganshin »

Hackbraten wrote: post #481
ui2RjUen875bfFA wrote: post #462

Earlier quoted context omitted.

those pipe usages are quite suspicious https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-n... https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-n... pipeing into this shell script which now uses "eval" https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-n... i guess this will be revisited and removed soon

> pipeing into this shell script which now uses "eval" I don’t actually see an issue with that `eval`. Why would one consider running `xz` followed by `eval`-ing its output more insecure than just running `xz`? If `xz` wants to do shenanigans with the privileges it already has, then it wouldn’t need `eval`’s help for that.

because in order to put backdoor into xz executable, you need to infect its sources. and in order to infect the sources, you need to use a similar technique to hide the modification

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#617

Post by CapstanRoller »

LtWorf wrote: post #581
hangonhn wrote: post #255

Earlier quoted context omitted.

I imagine it might be easier to just compromise a weakly protected account than to actual put in a 2 years long effort with real contributions. If we mandated MFA for all contributors who contribute to these really important projects then we can know with greater certainty if it was really a long con vs. a recently compromised account.

As I said recently in a talk I gave, 2FA as implemented by pypy or github is meaningless, when in fact all actions are performed via tokens that never expire, that are saved inside a .txt file on the disk.

Doesn't GH explicitly warn against using non-expiring tokens?

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#618

Post by korginator »

xz is so pervasive, I just discovered on my Mac that the (affected?) version 5.6.1 made it into homebrew. The post in the linked article says that only Linux x86-64 systems are affected, but now I'm left scratching my head whether my Mac is also in trouble, just that we don't know it yet.

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#619

Post by ikekkdcjkfke »

jaredallard2 wrote: post #545
returningfory2 wrote: post #93

A couple of years ago I wrote a Go library that wraps the xz C code and allows you to do xz compression in Go: https://github.com/jamespfennell/xz About a week ago I received the first PR on that repo, to upgrade to 5.6.1. I thought it was odd to get such a random PR...it's not the same GitHub account as upstream though.

Hey all, I’m the author of that PR. Just posted to Github with additional context: https://github.com/jamespfennell/xz/pull/2#issuecomment-2027...

The dopamine hits from updating stuff should come to an end, it should be thought of as adding potentially new bugs or exploits, unless the update fixes a CVE. Also Github needs to remove the green colors and checkmarks in PR's to prevent these dopamine traps from overriding any critical thinking

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#620

Post by transcriptase »

SilasX wrote: post #563
userbinator wrote: post #397

Earlier quoted context omitted.

because of it's "great new features" "great" for whom? I've seen enough of the industry to immediately feel suspicious when someone uses that sort of phrasing in an attempt to persuade me. It's no different from claiming a "better experience" or similar.

You can find more examples of that kind of puffer if you go to a website's cookie consent pop-up and find the clause after "we use cookies to...".

I’ve long thought that those “this new version fixes bugs and improves user experience” patch notes that Meta et al copy and paste on every release shouldn’t be permitted.
Post reply on HN