(Was waiting for a very long software build to finish and this idea popped into my head, so I decided to write it up and post it.)
A distro’s package manager is an interesting potential malware vector for a number of reasons. They are implicitly trusted by the distribution as being a safe source of software. The fact that these repositories are maintained by distributions and don’t simply allow anyone to throw software onto them increases their trustworthiness, and thus increases a user’s likelihood to treat them as entirely safe. Even though I do not (any longer) trust a distro’s official repos to be totally safe, I do generally trust sudo apt install to be more safe than most other ways of obtaining software.
However, while a distro’s repositories are indeed more safe than using the Internet at large as your software repository (thanks Windows for proving that), that doesn’t mean that a package manager is entirely safe:
- Very little code review is generally done when packaging a software application for several major distributions, including Debian. Debian does not require (or even particularly encourage) packagers to do a code review, and the people who review new packages to ensure they are suitable for inclusion into the Debian archives mostly check that the packaging looks good, not the code of the application. As a result it is very possible for a malicious package to be introduced into the archive on accident. Similarly, it’s possible for malicious code to be introduced into a previously legitimate application without anyone noticing. (This has happened at least twice before, once very notably in the xz-utils incident, and once in a lesser-known backdoor attack on the UnrealIRCD server, which affected Gentoo. That second attack went undetected for six or seven months.)
- Once a packager gets a package into the archive, they can provide updates for it in Debian Unstable with no or very little supervision. This is especially true if the packager is a Debian Maintainer (thus able to upload specific packages without needing a sponsor) or a Debian Developer (thus able to upload an update to any package without needing a sponsor). A malicious or compromised DM or DD could thus potentially introduce malicious code into the archive without being noticed. Supplying updates for a package in a stable release is harder and would probably not be so easy to compromise in this way thankfully, but you still are putting your trust in the DMs and DDs of Debian, which could be poorly placed. Remember that Jia Tan was fully trusted and that turned out to be a bad idea.
- Many software applications in Debian are outdated, meaning they could carry severe security-related bugs that make them unsafe to use even if they contain no intentionally malicoius code. The Chromium browser package is a good example of this - it was so often out-of-date that the Linux Mint developers decided to build it themselves for LMDE. Chromium, despite its apparently good security design, is also a massive source of security vulnerabilities probably because it is such a popular application and thus everyone’s looking for vulnerabilities in it. The problems with Chromium might not be as bad now as they were back then, but this kind of thing is still worrying.
- There are also packages that Debian just refuses to provide security support for because they’re so hard to support. I can’t remember an example right off the top of my head, but
check-support-statuscan be used to find packages one has installed that fall into this category. I seem to remember something WebKit related warning me about this once. - Users may enable third-party repositories to get software that isn’t available from the Debian archives, or that is outdated in Debian. These repositories are probably OK if the user is installing software from an official upstream source, but there’s nothing stopping someone from making a malicious Debian repo that advertises newer versions of outdated software to make itself attractive. There’s also the incident with a malicious third-party repo for Free Download Manager, which involved a compromise of the authentic Free Download Manager website. (That attack went undetected for around two years.)
All of these issues could potentially cause serious trouble even for a security-conscious user, and to my awareness no major operating system (Linux or otherwise) makes any attempt to significantly mitigate the risks these kinds of attacks introduce. (Debian’s check-support-status helps, but it only helps with one particular scenario, and it’s not even installed by default on Debian systems as far as I know. Similarly Windows’ and MacOS’s restrictions related to signed code can make it more difficult to run code by people who don’t provide a clear link between their software and their identity, but there’s nothing stopping someone from just publishing signed malicious code, plus identity theft is a thing.) The user is left to figure out what they do or don’t trust by themselves, and while the user should always be the final authority on what is or isn’t trusted, it should be recognized that some users are just plain bad at making good decisions about what to trust. As the saying goes, “Given a choice between dancing pigs and security, users will pick dancing pigs every time.”
How could we harden apt in order to make this problem less of a problem? We absolutely should not block users from installing software regardless of what that software is, but it might be a good idea to do something so that the user is given some pause for thought before doing something they probably shouldn’t do. One potential idea might be to wrap apt install commands to see what packages a user is trying to install, determine what sources apt will choose for installing these applications, and then check them against a database of “known good software” and another database of “known bad software”. If the user is trying to install something that isn’t explicitly trusted, they’ll get a warning they can click through, and if they’re trying to install something that is explicitly distrusted, they’ll get a dire warning that requires some effort to bypass. (Or maybe we make all warnings like this require some effort to bypass, although we do have to be careful that we don’t get backlash for “locking down” the OS if we go that route, then again I don’t think users expect us to be trying to mess up our users like Microsoft or Apple might do.) As for how these databases are built, we could add everything that is part of Kicksecure by default to the database, plus a bunch of widely-used software that isn’t suspected to be intrinsically dangerous. Specific third party repos for software like Element, Google Chrome, or Visual Studio Code could also be added. (Yes, I know that Google Chrome is debatable when it comes to whether it’s intrinsically dangerous or not, but you get my point.) We’d probably get some user complaints if we did this sort of thing, but we could always expand the database if people find things that we can determine are widely used, and for those who are using niche applications, they can expand the database themselves. This is just one potential application, I don’t know for sure if this is the best way of doing this, but it might work.