Technology

Jia Tan, University of Hong Kong in China. He’s been the sole maintainer of the package for almost two years.

You're making a logical fallacy called affirming the consequent where you're assuming that just because the backdoor was caught under these particular conditions, these are the only conditions under which it would've been caught.

Suppose the bad actor had not been sloppy; it would still be entirely possible that the backdoor gets identified and fixed during a security audit performed by an enterprise grade Linux distribution.

In this case it was caught especially early because the bad actor did not cover their tracks very well, but now that that has occurred, it cannot necessarily be proven one way or the other whether the backdoor would have been caught by other means.

Having once worked on an open source project that dealt with providing anonymity - it was considered the duty of the release engineer to have an overview of all code committed (and to ask questions, publicly if needed, if they had any doubts) - before compiling and signing the code.

On some months, that was a big load of work and it seemed possible that one person might miss something. So others were encouraged to read and report about irregularities too. I don't think anyone ever skipped it, because the implications were clear: "if one of us fails, someone somewhere can get imprisoned or killed, not to speak of milder results".

However, in case of an utility not directly involved with functions that are critical for security - it might be easier to pass through the sieve.

Auditing can be done only on open source code. No code = no audit. Reverse engieneering doesn't count.

Bystander effect, yes.

The answer is the same as closed source software: sometimes.

But that's beside the point, a security audit is not perfect. Plenty of audited codebases are the source of security vulnerabilities in the wild. We know based on analysis that the malicious actor's approach would have a high chance of successfully hiding from a typical security audit.

Across the board indeed. Scrutiny in code is one thing, where this story, as far as is known right now, really went south is the abuse of a trusted, but vulnerable, member of the community.

I know the (negative) spotlight is targeting Jia Tan right now (and who knows if they (still) exist), but I really hope Larhzu is doing okay. Who's name is mentioned in the same articles.

Mental health is a serious issue, that, if you read the back story, is easily ignored or abused. And it wasn't an unknown in this story. Don't only check the code, check up on your people too.

This is why I run debian oldstable.

Or maybe it's because I'm too lazy to do a dist-upgrade.

I honestly think the NSA has changed. If you look at the known backdoors they haven't got caught making any new backdoors since like 2010. Their MO also seems to be more hardware and encryption (more of an observational charter) than manipulation.

There's also evidence US Congress acted to stop the NSA from doing these underhanded tacits at least once https://www.wired.com/story/nsa-backdoors-closed/

They're not idiots, lots of smart people there that surely understand the risk of something like this to US national security interests. It's not the NSA that's been asking for encryption to be broken in recent years. They've been warning about quantum threats and ... from what I'm aware of actually been taking on the defensive role they were conducted to perform https://gizmodo.com/nsa-plans-to-act-now-to-ensure-quantum-computers-cant-b-1757038212

This seems like something that could actually be weaponized against predominantly western technology companies so I'd be very surprised if it was them and very surprised if they used someone that appears to be a Chinese born resident to do it.

I don't know man. Imagine you could have ssh access to every Debian and fedora server on the planet, and all you had to do was write tests for some compression library for 2 years and sneak in a clever patch. I'd guess such an exploit is worth millions. You wouldn't work 2 years for millions of dollars?

This is sophisticated but it doesn't have to be a state actor.

The malicious code is only thought to have affected deb/rpm packaging (i.e the backdoor only included itself with those packaging methods). Additionally, arch doesn't link ssh against liblzma which means this specific vulnerability wasn't applicable to arch. Arch may have still been vulnerable in other ways, but this specific vulnerability targeted deb/rpm distros

I liked the joke, but ya arch is not compromised. Check out this user's detailed comment.

https://feddit.de/comment/8782369

As the other person said it’s likely that xz is already installed on your system, but almost certainly a much older version than the compromised one. It’s likely that no action is required on your part assuming you’ve not been downloading tarballs of bleeding edge software.

As the other person said, just keep doing updates as soon Mint recommends them (since it’s based on Ubuntu LTS, it’s a lot less likely to have these bleeding edge vulnerabilities).

You're good. Even if you do use xz and ssh the version with the vulnerability only made it's way to rolling release distros or beta version of distros like fedora 40

It’s all systemds fault, got it.