3

Often, users will install additional package repositories to their Linux distributions to be able to follow "bleeding-edge" versions of software that hasn't been/will never be backported to their distribution version.

Say that packageA provided by repoA depends on libssl. Originally, no problems found; the only possible vulnerabilities would have to be supplied directly by packageA.

However, if the owner of the repository packages libssl and includes it in their own repository (I've seen similar things in the wild), my system libssl will be replaced by their compiled version of OpenSSL.

With this said, how difficult is it to do this? Do package managers (e.g. apt, yum) provide any protection against this? For all the user knows, a malicious repository could package a rootkit in a package called libssl which in fact doesn't provide any SSL support whatsoever. If I understand correctly, if this were to happen, the user would receive no indication that this was happening, and their machine would be compromised with a simple apt-get upgrade.

AviD
  • 73,317
  • 24
  • 140
  • 221
Naftuli Kay
  • 6,763
  • 11
  • 49
  • 78

2 Answers2

2

As a general rule most package managers will ask you if you want to install dependencies, as well as asking if you want install different (versions of) packages.

Whenever I download a package from somewhere that's not debian's repos (I use Crunchbang linux) then I'll install the needed dependencies myself and only use the third party repository for the one specific package I want.

Afterwards, I'll comment out the line in my sources file that has the third party repository so when I do run 'apt-get update' I won't get anything from that repository. (The only downside is it requires an additional step to update the package from that repository.)

Usually when you update or upgrade you'll be shown all the packages that need updating. If you pay attention, you'll notice anything funky going on.

Edit: Just found an example when trying to upgrade Mono

Need to get 55.8 MB of archives.
After this operation, 33.8 MB of additional disk space will be used.
Do you want to continue [Y/n]? Y
**WARNING: The following packages cannot be authenticated!**
  mono-complete mono-runtime-sgen mono-devel mono-dmcs...

It's from a non-Debian source, thus the warning and forcing me to select Y again.

Eric Lagergren
  • 2,351
  • 1
  • 13
  • 13
1

Essentially the concern you raise is valid.

The vendor of packageA could release a version of libssl that is higher than your distro's version of libssl. Next time you update libssl it will install the (newer) package from repoA. And/or the vendor of packageA could make their own package depend on their own version of libssl.

The manual mitigation step noted by @Eric Lagergren is certainly legit. However, there are 2 steps you can take to avoid the day-to-day the inconvenience of having to manually adjust the sources list every time you want to update and avoid the risk of forgetting, whilst still having some piece of mind. They are not foolproof and can still be undone, however it's still an improvement IMO.

  1. When you add the repo, DO NOT use apt-key add. Instead, put the key of the 3rd party repo somewhere else. E.g. /usr/share/keyrings/3rd-party-key.gpg and use a sources.list line that looks like this:

    deb [signed-by=/usr/share/keyrings/3rd-party-key.gpg] http...

  2. Make sure that you pin all packages from the repo (other than the one/ones you wish to install) at a low priority (e.g. 100). The specific packages you wish to install can be pinned to a higher number that will allow install (e.g. 500+).

Details of this configuration (and the remaining attack vectors) are noted on the Debian wiki. Also on the Debian wiki, another page discusses a potential resolution to the details of additional concerns raised here (Debian wiki again...).

Jeremy Davis
  • 163
  • 10