Reducing the risk of installing malicious apt packages?

(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-status can 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.

2 Likes

Related: There’s a ticket for check-support-status.

In case we implement this: Or we could keep apt unmodified and instead teach users to use our APT wrapper program instead with a name yet to be invented? (This is to avoid breaking existing scripts.)

This assumes, popular application = more secure?

I am worried to become something similar to a certificate authority. Becoming an entity that makes complicated decisions on “trustworthy” and “untrustworthy”. That seems difficult, opinionated to argue about without good reasons to back it up such as code audits, which we cannot provide due to lack of resources. Imagine software projects contacting us, asking why they’re on the bad list, why that is and how to get off the list.

Then imagine users wanting to install a program of their use case. A calculator or so. Our program would warn “this program has low popularity”. Then the user would ask in the forums what should be used instead. What’s the answer? Maybe there isn’t any popular calculator. The calculator is just a made up example. Could be any use case.

Can it be based on objective data? For example, if popularity is the primary decider, then we could base it on https://popcon.debian.org or other similar databases?

Or by looking into (Debian) CVE databases and warn against installing packages with known unpatched CVEs.

Why only about installing? It seems a tool that can also audit an already installed system would be useful as well. Similar to check-support-status but better.

1 Like

This idea reminds me of F-droid’s warning about anti-features.
I do however like this idea and the key points you raised.

Does Kicksecure ISO use debian unstable? I thought it used stable repository.

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

That a fair point also

That makes sense but would that be easy to maintain is there a database that could easily be queried of some sort.

It doesn’t.

“Once a packager gets a package into the archive, they can provide updates for it in Debian Unstable with no or very little supervision.” was only an accurate description/reminder how Linux distributions such as Debian are generally designed, describing general computer security issues. This doesn’t directly relate to derivatives such as Kicksecure repository default settings.

This might be a really hard problem to solve.

https://wiki.debian.org/DebianSecurity/debsecan

debsecan outputs a few thousand CVEs, but that’s overwhelming and not actionable.