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

681–690 of 1001 posts

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

#681

Post by BartjeD »

ncr100 wrote: post #258
move-on-by wrote: post #87

Fascinating. Just yesterday the author added a `SECURITY.md` file to the `xz-java` project. > If you discover a security vulnerability in this project please report it privately. *Do not disclose it as a public issue.* This gives us time to work with you to fix the issue before public exposure, reducing the chance that the exploit will be used before a patch is released. Reading that in a different light, it says giv…

Security Researchers : Is this request-for-private-disclosure + "90-days before public" reasonable? It's a SEVERE issue, to my mind, and 90 days seems too long to me.

The fraudulent author must have enjoyed the 'in joke' -- He's the one create vulnerabilities..

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

#682

Post by LtWorf »

2OEH8eoCRo0 wrote: post #272
0x0 wrote: post #67

Earlier quoted context omitted.

Wow, that's a lot of anonymous accounts adding comments there urging for a fast merge! And this "Hans Jansen" guy is apparently running around salsa.debian.org pushing for more updates in other projects as well: https://salsa.debian.org/users/hjansen/activity

And now we see why I don't trust anons, aliases, or anime characters to make contributions. My GitHub says exactly who I am!

It has been on the agenda for years to identify FOSS contributors with an id… Wet dream for authoritarians like you.

What would it solve when identity theft happens on a mass scale on a day to day basis?

It'd just ruin the life of some random person whose identity got stolen to create the account…

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

#683

Post by [deleted] »

EasyMark wrote: post #648
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.

they might not have been playing the long con. maybe approached by actors willing to pay them a lot of money to try and slip in a back door. I'm sure a deep dive into code contributions would clear that up for anyone familiar with the code base and some free time.

[deleted]

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

#684

Post by creatonez »

arp242 wrote: post #137
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.

As a bit of an aside, I would never accept a PR like this, and would always update $large_vendored_dependency myself. This is unreviewable, and trivial to insert any backdoor (unless you go through the motions of updating it yourself and diffing, at which point the PR becomes superfluous). I'd be wary even from a well-known author unless I knew them personally on some level (real-life or via internet). Not that I wou…

In this case, the project is using Git submodules for its vendored dependencies, so you can trivially cryptographically verify that they have vendored the correct dependency just by checking the commit hash. It looks really crazy on Github but in most git clients it will just display the commit hash change.

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

#685

Post by kgeist »

2OEH8eoCRo0 wrote: post #272
0x0 wrote: post #67

Earlier quoted context omitted.

Wow, that's a lot of anonymous accounts adding comments there urging for a fast merge! And this "Hans Jansen" guy is apparently running around salsa.debian.org pushing for more updates in other projects as well: https://salsa.debian.org/users/hjansen/activity

And now we see why I don't trust anons, aliases, or anime characters to make contributions. My GitHub says exactly who I am!

You can quite easily generate a realistic photo, bio, even entire personal blogs and GitHub projects, using generative AI, to make it look like it's a real person.

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

#686

Post by gamer191 »

hangonhn wrote: post #255
pfortuny wrote: post #159

Unfortunately, this is how good bad actors work: with a very long-term point of view. There is no “harmless” project any more.

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.

This PR from July 8 2023 is suspicious, so it was very likely a long con: https://github.com/google/oss-fuzz/pull/10667

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

#687

Post by alpb »

rpigab wrote: post #361

I'd love to be at Microsoft right now and have the power to review this user's connection history to Github, even though VPN exists, many things can be learned from connection habits, links to ISPs, maybe even guess if VPNs were used, roundtrip time on connections can give hints. I really don't think some random guy wants to weaken ssh just to extract some petty ransomware cash from a couple targets.

That’d be illegal for an employee to do.

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

#688

Post by jnxx »

jnxx wrote: post #665
jnxx wrote: post #477

Earlier quoted context omitted.

And, Joey Hess has counted at least 750 commits to xz from that handle. https://hachyderm.io/@joeyh/112180715824680521 This does not look trust-inspiring. If the code is complex, there could be many more exploits hiding.

If this is a conspiracy or a state-sponsored attack, they might have gone specifically for embedded devices and the linux kernel. Here archived from tukaani.org: https://web.archive.org/web/20110831134700/http://tukaani.or... > XZ Embedded is a relatively small decompressor for the XZ format. It was developed with the Linux kernel in mind, but is easily usable in other projects too. > *Features* > * Compiled code 8-2…

One scenario for malicious code in embedded devices would be a kind of killswitch which listens to a specific byte sequence and crashes when encountering it. For a state actor, having such an exploit would be gold.

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

#689

Post by _cenw »

0xthr0w4 wrote: post #339

Out of curiosity I looked at the list of followers of the account who committed the backdoor. Randomly picked https://github.com/Neustradamus and looked at all their contributions. Interestingly enough, they got Microsoft to upgrade ([0],[1]) `vcpkg` to liblzma 5.6.0 3 weeks ago. [0] https://github.com/microsoft/vcpkg/issues/37197 [1] https://github.com/microsoft/vcpkg/pull/37199

Hey, I remember this guy! Buddy of someone who tried to get a bunch of low quality stuff into ifupdown-ng, including copying code with an incompatible license and removing the notice. He's in every PR, complaining the "project is dead". He even pushes for the account to be made "team member".

https://github.com/ifupdown-ng/ifupdown-ng/pulls/easynetdev

He follows 54k accounts though, so it may indeed just be coincidence.

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

#690

Post by Retr0id »

The `pack`[0] compression utility that reached the HN front page the other day[1] is setting off my alarm bells right now. (It was at the time too, but now doubly so)

It's written in Pascal, and the only (semi-)documented way to build it yourself is to use a graphical IDE, and pull in pre-compiled library binaries (stored in the git repo of a dependency which afaict Pack is the only dependent of - appears to be maintained by the same pseudonymous author but from a different account).

I've opened an issue[2] outlining my concerns. I'm certainly not accusing them of having backdoored binaries, but if I was setting up a project to be deliberately backdoorable, it'd look a lot like this.

[0] https://pack.ac/

[1] https://news.ycombinator.com/item?id=39793805

[2] https://github.com/PackOrganization/Pack/issues/10

Post reply on HN