Hacker News Reader

Comment by rwmj | Hacker News Reader

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 project for 2 years, adding all sorts of binary test files, and to be honest with this level of sophistication I would be suspicious of even older versions of xz until proven otherwise.

View on HN

GitHub has suspended @JiaT75's account.

EDIT: Lasse Collin's account @Larhzu has also been suspended.

EDIT: Github has disabled all Tukaani repositories, including downloads from the releases page.

EDIT: Just did a bit of poking. xz-embedded was touched by Jia as well and it appears to be used in the linux kernel. I did quick look and it doesn't appear Jia touched anything of interest in there. I also checked the previous mirror at the tukaani project website, and nothing was out of place other than lagging a few commits behind:

https://gist.github.com/Qix-/f1a1b9a933e8847f56103bc14783ab7...

Here's a mailing list message from them ca. 2022.

https://listor.tp-sv.se/pipermail/tp-sv_listor.tp-sv.se/2022...

MinGW w64 on AUR was last published by Jia on Feb 29: https://aur.archlinux.org/cgit/aur.git/log/?h=mingw-w64-xz (found by searching their public key: 22D465F2B4C173803B20C6DE59FCF207FEA7F445)

pacman-static on AUR still lists their public key as a contributor, xz was last updated to 5.4.5 on 17-11-2023: https://aur.archlinux.org/cgit/aur.git/?h=pacman-static

EDIT: I've emailed the maintainer to have the key removed.

Alpine was patched as of 6 hours ago.

https://git.alpinelinux.org/aports/commit/?id=982d2c6bcbbb57...

OpenSUSE is still listing Jia's public key: https://sources.suse.com/SUSE:SLE-15-SP6:GA/xz/576e550c49a36... (cross-ref with https://web.archive.org/web/20240329235153/https://tukaani.o...)

EDIT: Spoke with some folks in the package channel on libera, seems to be a non-issue. It is not used as attestation nor an ACL.

Arch appears to still list Jia as an approved publisher, if I'm understanding this page correctly.

https://gitlab.archlinux.org/archlinux/packaging/packages/xz...

EDIT: Just sent an email to the last committer to bring it to their attention.

EDIT: It's been removed.

jiatan's Libera info indicates they registered on Dec 12 13:43:12 2022 with no timezone information.

    -NickServ- Information on jiatan (account jiatan):
    -NickServ- Registered : Dec 12 13:43:12 2022 +0000 (1y 15w 3d ago)
    -NickServ- Last seen : (less than two weeks ago)
    -NickServ- User seen : (less than two weeks ago)
    -NickServ- Flags : HideMail, Private
    -NickServ- jiatan has enabled nick protection
    -NickServ- *** End of Info ***

/whowas expired not too long ago, unfortunately. If anyone has it I'd love to know.

They are not registered on freenode.

EDIT: Libera has stated they have not received any requests for information from any agencies as of yet (30th Saturday March 2024 00:39:31 UTC).

EDIT: Jia Tan was using a VPN to connect; that's all I'll be sharing here.

Just for posterity since I can no longer edit: Libera staff has been firm and unrelenting in their position not to disclose anything whatsoever about the account. I obtained the last point on my own. Libera has made it clear they will not budge on this topic, which I applaud and respect. They were not involved whatsoever in ascertaining a VPN was used, and since that fact makes anything else about the connection information moot, there's nothing else to say about it.

The alpine patch includes gettext-dev which is likely also exploited as the same authors have been pushing gettext to projects where their changes have been questioned

What do you mean?

Look at the newest commits, do you see anything suspicious:

https://git.alpinelinux.org/aports/log/main/gettext

libunistring could also be affected as that has also been pushed there

Seeing so many commits that are "skip failing test" is a very strong code smell.

Yes, but it is often a sad reality of trying to run projects mainly written for glibc on musl. Not many people write portable C these days.

It's still the wrong way to go about things. Tests are there for a reason, meaning if they fail you should try to understand them to the point where you can fix the problem (broken test or actual bug) instead of just wantonly distabling tests until you get a green light.

> do you see anything suspicious

No.

> libunistring could also be affected as that has also been pushed there

What do you mean by "that"?

FWIW, that's mingw-w64-xz (cross-compiled xz utils) in AUR, not ming-w64 (which would normally refer to the compiler toolchain itself).

Good catch, thanks :)

> EDIT: Github has disabled all Tukaani repositories, including downloads from the releases page.

Why? Isn't it better to freeze them and let as many people as possible analyze the code?

You can still find the source everywhere, if you look for it. Having a fine-looking page distribute vulnerable source code is a much bigger threat.

Good question, though I can imagine they took this action for two reasons:

1. They don't have the ability to freeze repos (i.e. would require some engineering effort to implement it), as I've never seen them do that before.

2. Many distros (and I assume many enterprises) were still linking to the GitHub releases to source the infected tarballs for building. Disabling the repo prevents that.

The infected tarballs and repo are still available elsewhere for researchers to find, too.

They could always archive it. Theoretically (and I mean theoretically only), there's another reason for Microsoft to prevent access to repo: if a nation state was involved, and there've been backdoor conversations to obfuscate the trail.

Archiving the repo doesn't stop the downloads. They would need to rename it in order to prevent distro CI/CD from keeping downloading untrustworthy stuff.

Distros downloading directly from GitHub deserve what they get.

Maybe one can get the code from here. New commits being added it seems.

https://git.tukaani.org/

The latest commit is interesting (f9cf4c05edd14, "Fix sabotaged Landlock sandbox check").

It looks like one of Jia Tan's commits (328c52da8a2) added a stray "." character to a piece of C code that was part of a check for sandboxing support, which I guess would cause the code to fail to compile, causing the check to fail, causing the sandboxing to be disabled.

Lasse has also started his own documentation on the incident.

https://tukaani.org/xz-backdoor/

Shouldn't they have tests running to ensure that the check works on at least some systems?

What do you mean "tests"?

Have a system were you wxpect the sandboxing to work and have an automated check that it compiles there?

Part of the backdoor was in the tests. The attacker in this case could easily have sabotaged the test as well if a test was required.

If your project becomes complex enough eventually you need tests for the configure step. Even without malicious actors its easy to miss that a compiler or system change broke some check.

You can find it on archive. Someone archived it last night

Asking this here too: why isn't there an automated A/B or diff match for the tarball contents to match the repo, auto-flag with a warning if that happens? Am I missing something here?

The tarballs mismatching from the git tree is a feature, not a bug. Projects that use submodules may want to include these and projects using autoconf may want to generate and include the configure script.

Here is a longer explainer: https://www.redhat.com/en/blog/what-open-source-upstream

"lol"

> Those days are pretty much behind us. Sure, you can compile code and tweak software configurations if you want to--but most of the time, users don't want to. Organizations generally don't want to, they want to rely on certified products that they can vet for their environment and get support for. This is why enterprise open source exists. Users and organizations count on vendors to turn upstreams into coherent downstream products that meet their needs.

> In turn, vendors like Red Hat learn from customer requests and feedback about what features they need and want. That, then, benefits the upstream project in the form of new features and bugfixes, etc., and ultimately finds its way into products and the cycle continues.

"and when the upstream is tainted, everyone drinks poisoned water downstream, simple as that!"

> The tarballs mismatching from the git tree is a feature, not a bug.

A feature which allowed the exploit to take place, let's put it that way.

Over here: https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78b...

> The release tarballs upstream publishes don't have the same code that GitHub has. This is common in C projects so that downstream consumers don't need to remember how to run autotools and autoconf. The version of build-to-host.m4 in the release tarballs differs wildly from the upstream on GitHub.

Multiple suggestions on that thread on how that's a legacy practice that might be outdated, especially in the current climate of cyber threats.

Someone even posted a more thorough gist on what could be done to increase transparency and reduce discrepancies between tarballs and repos: https://gist.github.com/smintrh78/97b5cb4d8332ea4808f25b47c8...

I've posted an earlier WHOWAS of jiatan here: https://news.ycombinator.com/item?id=39868773

It appears to be an RCE, not a public key bypass: https://news.ycombinator.com/item?id=39877312

account is back online https://github.com/JiaT75

Hopefully still locked just visible so people can find and alayze his contributions.

I think this has been in the making for almost a year. The whole ifunc infrastructure was added in June 2023 by Hans Jansen and Jia Tan. The initial patch is "authored by" Lasse Collin in the git metadata, but the code actually came from Hans Jansen: https://github.com/tukaani-project/xz/commit/ee44863ae88e377...

> Thanks to Hans Jansen for the original patch.

https://github.com/tukaani-project/xz/pull/53

There were a ton of patches by these two subsequently because the ifunc code was breaking with all sorts of build options and obviously caused many problems with various sanitizers. Subsequently the configure script was modified multiple times to detect the use of sanitizers and abort the build unless either the sanitizer was disabled or the use of ifuncs was disabled. That would've masked the payload in many testing and debugging environments.

The hansjans162 Github account was created in 2023 and the only thing it did was add this code to liblzma. The same name later applied to do a NMU at Debian for the vulnerable version. Another "<name><number>" account (which only appears here, once) then pops up and asks for the vulnerable version to be imported: https://www.mail-archive.com/search?l=debian-bugs-dist@lists...

Also I saw this hans jansen user pushing for merging the 5.6.1 update in debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067708

From: krygorin4545 <krygorin4545@proton.me> To: "1067708@bugs.debian.org" <1067708@bugs.debian.org> Cc: "sebastian@breakpoint.cc" <sebastian@breakpoint.cc>, "bage@debian.org" <bage@debian.org> Subject: Re: RFS: xz-utils/5.6.1-0.1 [NMU] -- XZ-format compression utilities Date: Tue, 26 Mar 2024 19:27:47 +0000

Also seeing this bug. Extra valgrind output causes some failed tests for me. Looks like the new version will resolve it. Would like this new version so I can continue work.

Wow.

(Edited for clarity.)

Also I see this PR: https://github.com/tukaani-project/xz/pull/64

> because the ifunc code was breaking with all sorts of build options and obviously caused many problems with various sanitizers

for example, https://github.com/google/oss-fuzz/pull/10667

1 week ago "Hans Jansen" user "hjansen" was created in debian and opened 8 PRs including the upgrade to 5.6.1 to xz-utils

From https://salsa.debian.org/users/hjansen/activity

Author: Hans Jansen <hansjansen162@outlook.com>

- [Debian Games / empire](https://salsa.debian.org/games-team/empire): opened merge request "!2 New upstream version 1.17" - March 17, 2024

- [Debian Games / empire](https://salsa.debian.org/games-team/empire): opened merge request "!1 Update to upstream 1.17" - March 17, 2024

- [Debian Games / libretro / libretro-core-info](https://salsa.debian.org/games-team/libretro/libretro-core-i...): opened merge request "!2 New upstream version 1.17.0" - March 17, 2024

- [Debian Games / libretro / libretro-core-info](https://salsa.debian.org/games-team/libretro/libretro-core-i...): opened merge request "!1 Update to upstream 1.17.0" - March 17, 2024

- [Debian Games / endless-sky](https://salsa.debian.org/games-team/endless-sky): opened merge request "!6 Update upstream branch to 0.10.6" - March 17, 2024

- [Debian Games / endless-sky](https://salsa.debian.org/games-team/endless-sky): opened merge request "!5 Update to upstream 0.10.6" - March 17, 2024

- [Debian / Xz Utils](https://salsa.debian.org/debian/xz-utils): opened merge request "!1 Update to upstream 5.6.1" - March 17, 2024

That looks exactly like what you'd want to see to disguise the actual request you want, a number of pointless upstream updates in things that are mostly ignored, and then the one you want.

glad I didn't merge it ...

Wow, what a big pile of infrastructure for a non-optimization.

An internal call via ifunc is not magic — it’s just a call via the GOT or PLT, which boils down to function pointers. An internal call through a hidden visibility function pointer (the right way to do this) is also a function pointer.

The even better solution is a plain old if statement, which implements the very very fancy “devirtualization” optimization, and the result will be effectively predicted on most CPUs and is not subject to the whole pile of issue that retpolines are needed to work around.

Right, IFUNCs make sense for library function where you have the function pointer indirection anyway. Makes much less sense for internal functions - only argument over a regular function pointer would be the pointer being marked RO after it is resolved (if the library was linked with -z relro -z now), but an if avoids even that issue.

>Hans Jansen and Jia Tan

Are they really two people conspiring?

Unless proven otherwise, it is safe to assume one is just a pseudonym alias of the other.

or possibly just one person acting as two, or a group of people?

Or a group managing many identities, backdooring many different projects

Make it two years.

Jia Tan getting maintainer access looks like it is almost certainly to be part of the operation. Lasse Colling mentioned multiple times how Jia has helped off-list and to me it seems like Jia befriended Lasse as well (see how Lasse talks about them in 2023).

Also the pattern of astroturfing dates back to 2022. See for example this thread where Jia, who has helped at this point for a few weeks, posts a patch, and a <name><number>@protonmail (jigarkumar17) user pops up and then bumps the thread three times(!) lamenting the slowness of the project and pushing for Jia to get commit access: https://www.mail-archive.com/xz-devel@tukaani.org/msg00553.h...

Naturally, like in the other instances of this happening, this user only appears once on the internet.

Does anybody know anything about Jia Tan? Is it likely just a made up persona? Or is this a well-known person.

It’s certainly a pseudonym just like all the other personas we’ve seen popping up on the mailing list supporting this “Jia Tan” in these couple of years. For all intents and purposes they can be of any nationality until we know more.

It seems like Hans Jansen has also an account on proton.me (hansjansen162@proton.me) with the Outlook address configured as recovery-email.

Yesterday sure was fun wasn't it :p Thanks for all your help/working with me on getting this cleaned up in Fedora.

Is it normal that when I try to uninstall xz it is trying to install lzma?

It means that `xz` was depended upon by something that depends on eg "xz OR lzma"

PSA: I just noticed homebrew installed the compromised version on my Mac as a dependency of some other package. You may want to check this to see what version you get:

   xz --version

Homebrew has already taken action, a `brew upgrade` will downgrade back to the last known good version.

Thanks for this. I just ran brew upgrade and the result was as you described:

  xz 5.6.1 -> 5.4.6

I also had a homebrew installed affected version.

I understand it's unlikely, but is there anything I can do to check if the backdoor was used? Also any other steps I should take after "brew upgrade"?

Quoting[1] from Homebrew on Github:

>> Looks like that Homebrew users (both macOS and Linux, both Intel and ARM) are unlikely affected?

> Correct. Though we do not appear to be affected, this revert was done out of an abundance of caution.

[1] https://github.com/Homebrew/homebrew-core/pull/167512

Is it actually compromised on homebrew though? I guess we can't be sure but it seemed to be checking if it was being packaged as .deb or .rpm?

Is 5.2.2 safe? Just 5.6.0 and 5.6.1 are bad?

sorry, what exact version(s) is the one(s) affected again?

(or SHAs, etc.)

(EDIT: 5.6.0 and 5.6.1 ?)

(EDIT 2: Ooof, looks like the nix unstable channel uses xz 5.6.1 at this time)

I use Nix to manage this stuff on Mac, not Homebrew...

GitHub disabled the xz repo, making it a bit more difficult for nix to revert to an older version. They've made a fix, but it will take several more days for the build systems to finish rebuilding the ~220,000 packages that depend on the bootstrap utils.

Here is the discussion https://github.com/NixOS/nixpkgs/issues/300055

Lol they shouldn't be relying on GitHub in the first place.

What should they be relying on instead? Maybe rsync everything to an FTP server? Or Torrents? From your other comments, you seem to think no one should ever use GitHub for anything.

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.

Tell me about it. I look at all these random updates that get pushed to my mobile phone and they all pretty much have that kind of fluff in the description. Apple/Android should take some steps to improve this or outright ban this practice. In terms of importance to them though I imagine this is pretty low on the list.

I have dreamed about an automated LLM system that can "diff" the changes out of the binary and provide some insight. You know give back a tiny bit of power to the user. I'll keep dreaming.

It's worse, as someone who does try to privide release notes I'm often cut off by the max length of the field. And even then, Play only shows you the notes for the latest version of the app.

Slack's Mac app release notes [1] rotate a few copy pastes, here's the one that shits me the most.

> We tuned up the engine and gave the interiors a thorough clean. Everything is now running smoothly again.

Yeah nah mate, if every release is the first release where everything is running smoothly, I'm not going to believe it this time either.

Makes me wonder if the team has some release quota to fill and will push a build even if nothing meaningful has actually changed.

[1] https://slack.com/release-notes/mac

Ugh. That's especially annoying because they're trying to be hip with slang and use a metaphor that requires cultural knowledge that you can't really assume everyone has.

I made a library where version 2 is really really much faster than version 1. I'd want everyone to just move to version 2.

But then you are saying a specific great new feature, performance, and not just the claim and concept performance, but numbers.

I'm sure they actually had new features…

Yeah... RISCV routine was put in, then some binary test files were added later that are probably now suspect.

don't miss out on the quality code, like the line that has: i += 4 - 2;

https://git.tukaani.org/?p=xz.git;a=commitdiff;h=50255feeaab...

> some binary test files were added later that are probably now suspect

That's confirmed

From https://www.openwall.com/lists/oss-security/2024/03/29/4:

> The files containing the bulk of the exploit are in an obfuscated form in

> tests/files/bad-3-corrupt_lzma2.xz

> tests/files/good-large_compressed.lzma

> committed upstream. They were initially added in

> https://github.com/tukaani-project/xz/commit/cf44e4b7f5dfdbf...

It probably makes sense to start isolating build processes from test case resources.

Sure but then you can smuggle it into basically any other part of the build process…?

FWIW, "4 - 2" is explained earlier in the file:

  // The "-2" is included because the for-loop will
  // always increment by 2. In this case, we want to
  // skip an extra 2 bytes since we used 4 bytes
  // of input.
  i += 4 - 2;

What are they specifically?

I don't know how you can be missing the essence of the problem here or that comments point.

Vague claims are meaningless and valueless and are now even worse than that, they are a red flag.

Please don't tell me that you would accept a pr that didn't explain what it did, and why it did it, and how it did it, with code that actually matched up with the claim, and was all actually something you wanted or agreed was a good change to your project.

Updating to the next version of a library is completely unrelated. When you update a library, you don't know what all the changes were to the library, _but the librarys maintainers do_, and you essentially trust that librarys maintainers to be doing their job not accepting random patches that might do anything.

Updating a dependency and trusting a project to be sane is entirely a different prospect from accepting a pr and just trusting that the submitter only did things that are both well intentioned and well executed.

If you don't get this then I for sure will not be using or trusting your library.

Interesting that one of the commits commented on update of the test file that it was for better reproducibility for having been generated by a fixed random seed (although how goes unmentioned). For the future, random test data better be generated as part of the build, rather than being committed as opaque blobs...

I agree on principle, but sometimes programmatic generating test data is not so easy.

E.g.: I have a specific JPEG committed into a repository because it triggers a specific issue when reading its metadata. It's not just _random_ data, but specific bogus data.

But yeah, if the test blob is purely random, then you can just commit a seed and generate in during tests.

Debian have reverted xz-utils (in unstable) to 5.4.5 – actual version string is “5.6.1+really5.4.5-1”. So presumably that version's safe; we shall see…

Is that version truly vetted? "Jia Tan" has been the official maintainer since 5.4.3, could have pushed code under any other pseudonym, and controls the signing keys. I would have felt better about reverting farther back, xz hasn't had any breaking changes for a long time.

It's not only that account, other maintainer has been pushing the same promotion all over the place.

It looks like this is being discussed, with a complication of additional symbols that were introduced https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068024

Thanks for this! I found this URL in the thread very interesting!

https://www.nongnu.org/lzip/xz_inadequate.html

It is an excellent technical write-up and yet again another testimonial to the importance of keeping things simple.

The other comments here showing that the backdoor was a long-term effort now make me wonder just how long of an effort it was...

There are suggestions to roll back further

TIL that +really is a canonical string. [0]

[0]: https://www.debian.org/doc/debian-policy/ch-controlfields.ht...

After reading the original post by Andres Freund, https://www.openwall.com/lists/oss-security/2024/03/29/4, his analysis indicates that the RSA_public_decrypt function is being redirected to the malware code. Since RSA_public_decrypt is only used in the context of RSA public key - private key authentication, can we reasonably conclude that the backdoor does not affect username-password authentication?

Isn't it rather that the attacker can log in to the compromised server by exploiting the RSA code path?

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.

Imagine if sshd was distributed by PyPI or cargo or npm instead of by a distro.

Github accounts of both xz maintainers have been suspended.

Not true, the original author wasn't suspended: https://github.com/Larhzu

https://github.com/JiaT75 was suspended for a moment, but isn't anymore?

Both are suspended for me. Check followers on both accounts, both have a suspended pill right next to their names.

Ah, thanks for correcting me there - really weird that this isn't visible from the profile itself. Not even from the organization.

The following page for each other show both accounts suspended indeed.

https://github.com/Larhzu?tab=following

https://github.com/JiaT75?tab=following

Lasse's account was restored

github should add a badge for "inject backdoor into core open source infrastructure"

Hey maybe it would get bad actors to come clean trying to get that badge.

GitHub’s UI has been getting notoriously bad for showing consistent and timely information lately, could be an issue stemming from that.

Yeah. Had a weird problem last week where GitHub was serving old source code from the raw url when using curl, but showing the latest source when coming from a browser.

Super frustrating when trying to develop automation. :(

These shouldn't be suspended, and neither should their repositories. People might want to dig through the source code. It's okay if they add a warning on the repository, but suspending _everything_ is a stupid thing to do.

Tools don't read warnings. Of course the information should not be hidden completely but intentionally breaking the download URLs makes sense.

This can also be handled relatively easily. They can disable the old links and a new one can be added specifically for the disabled repository. Or even just let the repository be browsable through the interface at least.

Simply showing one giant page saying "This respository is disabled" is not helpful in any way.

Do you know if it was actually the commit author, of if their commit access was compromised?

If it was a compromise it also included the signing keys as the release tarball was modified vs the source available on GitHub.

Nice. I worked on a Linux disto when I was a wee lad and all we did was compute a new md5 and ship it.

Name and shame this author. They should never be allowed anywhere near any open projects ever again.

They might have burnt the reputation built for this particular pseudonym but what is stopping them from doing it again? They were clearly in it for the long run.

You're assuming that it's even a single person, it's just a gmail address and an avatar with a j icon from a clip art thing.

I literally said "they", I know, I know, in English that can also be interpreted as a gender unspecific singular.

Anyways, yes it is an interesting question whether he/she is alone or they are a group. Conway's law probably applies here as well. And my hunch in general is that these criminal mad minds operate individually / alone. Maybe they are hired by an agency but I don't count that as a group effort.

Please don't?

1. You don't actually know what has been done by whom or why. You don't know if the author intended all of this, or if their account was compromised. You don't know if someone is pretending to be someone else. You don't know if this person was being blackmailed, forced against their will, etc. You don't really know much of anything, except a backdoor was introduced by somebody.

2. Assuming the author did do something maliciously, relying on personal reputation is bad security practice. The majority of successful security attacks come from insiders. You have to trust insiders, because someone has to get work done, and you don't know who's an insider attacker until they are found out. It's therefore a best security practice to limit access, provide audit logs, sign artifacts, etc, so you can trace back where an incursion happened, identify poisoned artifacts, remove them, etc. Just saying "let's ostracize Phil and hope this never happens again" doesn't work.

3. A lot of today's famous and important security researchers were, at one time or another, absolute dirtbags who did bad things. Human beings are fallible. But human beings can also grow and change. Nobody wants to listen to reason or compassion when their blood is up, so nobody wants to hear this right now. But that's why it needs to be said now. If someone is found guilty beyond a reasonable doubt (that's really the important part...), then name and shame, sure, shame can work wonders. But at some point people need to be given another chance.

100% fair -- we don't know if their account was compromised or if they meant to do this intentionally.

If it were me I'd be doing damage control to clear my name if my account was hacked and abused in this manner.

Otherwise if I was doing this knowing full well what would happen then full, complete defederation of me and my ability to contribute to anything ever again should commence -- the open source world is too open to such attacks where things are developed by people who assume good faith actors.

upon further reflection all 3 of your points are cogent and fair and valid. my original point was a knee-jerk reaction to this. :/

Your being able to reflect upon it and analyze your own reaction is rare, valuable and appreciated

I think I went through all the stages of grief. Now at the stage of acceptance here’s what I hope: I hope justice is done. Whoever is doing this be they a misguided current black hat (hopefully, future white hat) hacker, or just someone or someones that want to see the world burn or something in between that we see justice. And then forgiveness and acceptance and all that can happen later.

Mitnick reformed after he was convicted (whether you think that was warranted or not). Here if these folks are Mitnick’s or bad actors etc let’s get all the facts on the table and figure this out.

What’s clear is that we all need to be ever vigilant: that seemingly innocent patch could be part of a more nefarious thing.

We’ve seen it before with that university sending patches to the kernel to “test” how well the core team was at security and how well that went over.

Anyways. Yeah. Glad you all allowed me to grow. And I learned that I have an emotional connection to open source for better or worse: so much of my life professional and otherwise is enabled by it and so threats to it I guess I take personally.

It is reasonable to consider all commits introduced by the backdoor author untrustworthy. This doesn't mean all of it is backdoored, but if they were capable of introducing this backdoor, their code needs scrutiny. I don't care why they did it, whether it's a state-sponsored attack, a long game that was supposed to end with selling a backdoor for all Linux machines out there for bazillions of dollars, or blackmail — this is a serious incident that should eliminate them from open-source contributions and the xz project.

There is no requirement to use your real name when contributing to open source projects. The name of the backdoor author ("Jia Tan") might be fake. If it isn't, and if somehow they are found to be innocent (which I doubt, looking at the evidence throughout the thread), they can create a new account with a new fake identity.

Can legal action be taken against the author if it's found he maliciously added the backdoor?

Good luck with that. We don't even know what country is he from. Probably from China but even if so. Good luck finding him among 1.5 Billions.

It is not good to take into consideration something with any unreadable text instead of the open text of the programme. It should be excluded.

I wonder who the target was!

Every Linux box inside AWS, Azure, and GCP and other cloud providers that retains the default admin sudo-able user (e.g., “ec2”) and is running ssh on port 22.

I bet they intended for their back door to eventually be merged into the base Amazon Linux image.

my understanding is that any Debian/RPM-based Linux running sshd would become vulnerable in a year or two. The best equivalent of this exploit is the One Ring.

So the really strange thing is why they put so little effort into making this undetectable. All they needed was to make it use less time to check each login attempt.

In the other hand it was very hard to detect. The slow login time was the only thing that gave it away. It more seems like they were so close to being highly successful. In retrospect improving the performance would have been the smart play. But that is one part that went wrong compared to very many that went right.

You don't need a "ec2" user. A backdoor can just allow root login even when that is disabled for people not using the backdoor.

It just requires the SSH port to be reachable unless there is also a callout function (which is risky as people might see the traffic). And with Debian and Fedora covered and the change eventually making its way into Ubuntu and RHEL pretty much everything would have this backdoor.

Probably less of an individual and more of an exploit to sell.

Distro build hosts and distro package maintainers might not be a bad guess. Depends on whether getting this shipped was the final goal. It might have been just the beginning, part of some bootstrapping.

his account is active again on github https://github.com/JiaT75

Sleeper.

the account was either sold or stolen

That's pure speculation and there are plenty of hints to the contrary.

Reply on news.ycombinator.com