181–190 of 1001 posts
Earlier quoted context omitted.
Thanks to autoconf, we're now used to build scripts looking like gibberish. A perfect place to hide a backdoor.
This is my main take-away from this. We must stop using upstream configure and other "binary" scripts. Delete them all and run "autoreconf -fi" to recreate them. (Debian already does something like this I think.)
So many security companies publishing daily generic blog posts about "serious supply chain compromises" in various distros on packages with 0 downloads, and yet it takes a developer debugging performance issues to find an actual compromise. I worked in the software supply chain field and cannot resist feeling the entire point of that industry is to make companies pay for a security certificate so you can shift the bl…
If you installed xz on macOS using brew, then you have xz (XZ Utils) 5.6.1 liblzma 5.6.1 which are within the release target for the vuln. As elsewhere in these comments, people say macOS effect is uncertain. If concerned you can revert to 5.4.6 with brew upgrade xz
5.6.1 was available for a few days and just rolled back ~20 minutes ago: https://github.com/macports/macports-ports/commit/a1388aee09...
The discussion to upload it to Debian is interesting on its own https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067708
A lot of eyes will be dissecting this specific exploit, and investigating this specific account, but how can we find the same kind of attack in a general way if it’s being used in other projects and using other contributor names?
This attack can be stopped by disallowing any binary testdata or other non-source code to be on the build machines during a build.
You could imagine a simple process which checks out the code, then runs some kind of entropy checker over the code to check it is all unminified and uncompressed source code, before finally kicking off the build process.
autogenerated files would also not be allowed to be in the source repo - they're too long and could easily hide bad stuff. Instead the build process should generate the file during the build.
Earlier quoted context omitted.
I mean, a backdoor at this scale (particularly if it wasn't noticed for a while and got into stable distros) could be worth millions. Maybe hundreds of millions (think of the insider trading possibilities alone, not to mention espionage). 2 years doesn't seem like that much work relative to the potential pay off. This is the sort of case where america's over the top hacking laws make sense.
And what law would you use to target someone who wrote some code and posted it for free on the internet that was willingly consumed?
Yikes! Do you have any info on the individual's background or possible motivations?
There is zero web presence for this person and associated email address. Looks more likely a fake identity than compromised account.
https://char.tw/blog/post/24397301
Earlier quoted context omitted.
Name and shame this author. They should never be allowed anywhere near any open projects ever again.
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 di…
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.
Safety through obscurity and weirdness! If you disable ifunc, like any sensible person, this backdoor disables itself.
Interesting, I used https://ossinsight.io/analyze/JiaT75 to identify contributions from the account used by author of the backdoor. It looks like the account made other potentially problematic contributions to other projects. The disabling of ifunc in this PR against Google's oss-fuzz project maybe one way they tried to prevent this particular backdoor being flagged by that tool? https://github.com/google/oss-fuzz/pu…