931–940 of 1001 posts
Is the solution against such attacks in the future only to scrutinize more, or are there other reasonable options in terms of hardening?
Since GitHub disabled the repos.. I uploaded all GitHub Events from the two suspected users and from their shared project repo as easy to consume CSV files: https://github.com/emirkmo/xz-backdoor-github For those who want to see the GitHub events (commits, comments, pull_requets, diffs, etc.)
Was Debian 12/stable unaffected? Only sid?
I hope Lasse Collin is doing OK! Here is a older message from him [1] "I haven't lost interest but my ability to care has been fairly limited mostly due to longterm mental health issues but also due to some other things. Recently I've worked off-list a bit with Jia Tan on XZ Utils and perhaps he will have a bigger role in the future, we'll see. It's also good to keep in mind that this is an unpaid hobby project. " Gi…
Lasse appears to be active and working on undoing the sabotage. https://git.tukaani.org/?p=xz.git;a=blobdiff;f=CMakeLists.tx...
Yikes! Do you have any info on the individual's background or possible motivations?
I would presume it's a state actor. Generally in the blackhat world, attackers have very precise targets. They want to attack this company or this group of individuals. But someone who backdoors such a core piece of open source infrastructure wants to cast a wide net to attack as many as possible. So that fits the profile of a government intelligence agency who is interested in surveilling, well, everything. Or it co…
Earlier quoted context omitted.
> So when are we going to stop pretending ... I'm not sure that we are. Doesn't everybody know that developing/maintaining free software is largely thankless work, with little to no direct recompense? I don't think moving towards unfree software is a good way to make free software more secure. It shouldn't be a surprise that proprietary software is less likely to be exploited in this way simply because they don't acc…
> Doesn't everybody know that developing/maintaining free software is largely thankless work, with little to no direct recompense? No I don't think that is a universally acknowledged feeling. Numerous maintainers have detailed recieving entitled demands from users, as if they were paying customers to the open source software projects. Georges Stavracas' interview on the Tech over Tea podcast^1 describes many such exp…
What I'm saying is that paying people (or having a trusted security team) to work on software necessarily makes it less free. Note that "less free" doesn't mean worthless and absolutely free isn't the ideal.
Sorry, I used "everybody" to mean a subset of everybody -- the "we" that you referred to, or people generally involved in open source software development.
> it's a shame that so many people know, and yet are unwilling to financially support developers to change that.
Regardless of which set of everyone, this is undoubtedly the case. However, I'm not sure that paying (some of) the developers a wage is the best way to improve the software, particularly as free software.
> initiatives like DigitalOcean's Hacktoberfest, are designed to do just this.
You've got this backwards. Hacktoberfest is a scheme to pay (more) people to contribute (more) to open source projects. This is an example of why paying people to work on open source doesn't necessarily improve the software. It also doesn't lower any barriers, it just increases the incentive to overcome them.
So while this might increase the number of people contributing[0] to open source projects, it doesn't directly increase the number of people who understand and care about the specific project they're contributing to, let alone the broader free software movement.
In short, you can't pay people to care.
[0] according to their pretty weak metric for what contributing is
Yikes! Do you have any info on the individual's background or possible motivations?
Kinda relevant, as I saw few comments about how safer languages are the solution. Here[0] is a very simple example, that shows how easy such supply chain attacks are in Rust; and lets not forget that there was a very large python attack just a few days ago[1]. [0] - https://github.com/c-skills/rust1 [1] - https://checkmarx.com/blog/over-170k-users-affected-by-attac...
I am very concerned about Rust. Rust’s “decision” to have a very slim standard library has advantages, but it severely amplifies some other issues. In Go, I have to pull in zero dependencies to make an HTTP request. In Rust, pulling reqwest pulls in at least 30 distinct packages ( https://lib.rs/crates/reqwest ). Date/time, “basic” base64, common hashing or checksums, etc, they all become supply chain vectors. The Ru…
This would be less of a problem if each dependency (and in turn, their dependencies) were individually sandboxed, and only allowed to access specific inputs/files at runtime in the capability security (https://en.wikipedia.org/wiki/Capability-based_security) fashion.
This way the attack surface would be hollowed out as much as possible, and exploits limited to the (sub)program output or specific accessible (writable) files.
I am taking the initiative to gather more information regarding the possible precursors and perpetrators of the backdoor.
The purpose of this commentary is focused on open source information (OSINT).
I am not a judge of anyone or any action that may occur, the objective of this comment is to help through accurate and quick information to help the core developers of the affected packages and consequently the Linux kernel (which may have been indirectly or directly affected) take action necessary in relation to the fact that occurred.
NOTE: This comment will always have "edit" so always review it for information.
Information I have so far.
Summary: 1. GitHub Account Suspension: - The accounts of @JiaT75 and @Larhzu were suspended by GitHub. - All Tukaani repositories, including downloads, were disabled. - Investigate the cause of the account suspensions and whether there is any correlation with suspicious activities.
2. Possible Backdoor in xz/liblzma: - There are concerns about the presence of a backdoor in xz/liblzma. - Investigate whether there is evidence of compromise in the source code and recent updates. - Examine potential impacts, especially if the software is used in critical systems.
3. Updates and Patches in Packages: - Note recent updates in packages such as MinGW w64, pacman-static, Alpine, and OpenSUSE. - Review changelogs to understand if these updates are related to security fixes.
4. Jia's Activities on Platforms and Projects: - Investigate Jia's contributions to different projects and platforms, such as Arch Linux, Alpine Linux, and OpenSUSE. - Check for correlations between Jia's activities and reported security issues.
5. Libera Registration Information: - Analyze Jia's registration details on Libera to determine the timeline of their online activities. - Consider correlating this information with other online activities of Jia.
6. VPN Usage: - Confirm Jia's use of VPN and assess its impact on security investigations. - Explore possible reasons for using a VPN and how it may affect the identification and tracking of online activities.
Links related to user JiaT75 [xz] Remove JiaT75 as a contact, determine correct contacts #11760 - Google/oss-fuzz https://github.com/google/oss-fuzz/issues/11760
Tuktest index hash #7 - tukaani-project/xz/pull/7 https://web.archive.org/web/20240329230522/https://github.co...
So much damage is caused just by adding a single maintainer to a project - imagine how much power you would have to wield the remote execution systems put in place by naive developers for "automatic updates".
All it takes is a single malicious maintainer given access to the new version update of some popular user software, and they have a new botnet of thousands of devices at their disposal. Better yet, after the backdoor installation, they can just release the real update and cover their tracks forever.
Automatic updates are like running web applications, but without any sandboxing or protection usually implemented by the browser.