Source: https://infosec.exchange/@fr0gger/112189232773640259

Pretty bad is also that it intersects with another problem: Bus factor.

Having just one person as maintainer of a library is pretty bad. All it takes is one accident and no one knows how to maintain it.
So, you're encouraged to add more maintainers to your project.

But yeah, who do you add, if it's a security-critical project? Unless you happen to have a friend that wants to get in on it, you're basically always picking a stranger.

• Careful choice of program to infect the whole Linux ecosystem
• Time it took to gain trust
• Level of sophistication in introducing backdoor in open source product

All of these are signs of persistent threat actors aka State sponsor hacker. Though the real motive we would never know as it's now a failed project.

Hopefully shows why you should never trust closed source software

If the world didn’t have source access then we would have never found it

"Paid for by a state actor" Yes, who knows.

• Could be a lone "black hat" or a group of "black hats". Who knows.

• Could be the result of a lot of public criticism in the news regarding Pegasus spyware. Who knows.

• Could be paid by companies without any state actors involved. Who knows.

• Could be a lone programmer who wants power or is seeking revenge for some heated mailing list discussion. Who knows.

The question of trust has been mentioned in this case of a sole maintainer with health problems. What I asked myself is : How did this trust develop years ago ? People trusted Linus Torvalds and used the Linux kernel to build Linux distributions with to the point that the Linux kernel became from a tiny hobby thing a giant project. At some point compiling from source code became less fashionable and most people downloaded and installed binaries. New projects started and instead of tar and gzip things like xz and zstd were embraced. When do you trust a person or a project, and who else gets on board of a project ? Nowadays something like :

curl -sSL https://yadayada-flintstones-revival.com | bash

is considered perfectly normal as the default installation of some software. Open source software is cool and has kind of produced a sort of revolution in technology but there is still a lot of work to do.

Any speculations on the target(s) of the attack? With stuxnet the US and Israel were willing to to infect the the whole world to target a few nuclear centrifuges in Iran.

Source: https://mastodon.social/@bagder/112192351400749028

I had assumed it was probably a state sponsored attack. This looks like it was planned from the beginning, and any cyber attack that had years of planning and waiting strikes me as state-sponsored.

Historically there have been several instances of anarcho-communist organizations and social movements flourishing.

Most of them were sabotaged by plutocrat agents invoking violence or mischief. Often just giving an angry militants in the region some materiel support and bad intel.

What if the unexpected SSH latency hadn’t been introduced, this backdoor would live?

I wonder how many OSS projects include backdoors that doesn't appear in performance checks

~~Linux~~ Unix since 1979: upon booting, the kernel shall run a single "init" process with unlimited permissions. Said process should be as small and simple as humanly possible and its only duty will be to spawn other, more restricted processes.

Linux since 2010: let's write an enormous, complex system(d) that does everything from launching processes to maintaining user login sessions to DNS caching to device mounting to running daemons and monitoring daemons. All we need to do is write flawless code with no security issues.

Linux since 2015: We should patch unrelated packages so they send notifications to our humongous system manager whether they're still running properly. It's totally fine to make a bridge from a process that accepts data from outside before even logging in and our absolutely secure system manager.

Excuse the cheap systemd trolling, yes, it is actually splitting into several, less-privileged processes, but I do consider the entire design unsound. Not least because it creates a single, large provider of connection points that becomes ever more difficult to replace or create alternatives to (similarly to web standard if only a single browser implementation existed).

I'm curious to know about the distro maintainers that were running bleeding edge with this exploit present. How do we know the bad actors didn't compromise their systems in the interim ?

The potential of this would have been catastrophic had it made its way into the stable versions, they could have for example accessed the build server for tor or tails or signal and targeted the build processes . not to mention banks and governments and who knows what else... Scary.

I'm hoping things change and we start looking at improving processes in the whole chain. I'd be interested to see discussions in this area.

I think the fact they targeted this package means that other similar packages will be attacked. A good first step would be identifying those packages used by many projects and with one or very few devs even more so if it has root access. More Devs means chances of scrutiny so they would likely go for packages with one or few devs to improve the odds of success.

I also think there needs to be an audit of every package shipped in the distros. A huge undertaking , perhaps it can be crowdsourced and the big companies FAAGMN etc should heavily step up here and set up a fund for audits .

What do you think could be done to mitigate or prevent this in future ?

Interesting to hear and it wouldn't surprise me either tbh. At least none of my systems were vulnerable apparently, which is good because I am running the latest Ubuntu LTS and latest Proxmox - if those were affected then wow this would have affected so many more people.