28

Are repository updates secure?

As a bear of little brain from the developer side, I cannot understand why the repository list is http://security.ubuntu.com and the other http(unsecured) sites listed in /etc/apt/sources.list. Without a certificate chain match this appears as "ask any responder for a list of packages to update" instead of "ask the ubuntu.com site..."

Can any network choose to spoof the update sites, and is this a common practice to provide a locally cached and vetted copy?

0
33

In short, yes they're secure, because of public key cryptography used to sign the files.

All the files downloaded by APT have a signature that allows the downloaded file to be verified against the public keys stored on your computer as being signed by Ubuntu and only Ubuntu. This verifies that the file you receive was authorised by Ubuntu at some stage and hasn't been modified or tampered with since.

A technical explanation of how this works is available from Ubuntu (and from Debian which uses the same system).

Because of the use of HTTP instead of HTTPS, yes eavesdroppers could see what files you are downloading, but privacy is not likely to be your concern in this case. A man-in-the-middle attempt to modify the packages to inject harmful code would still fail because it would break the signing mechanism.

One possible gotcha in this signing mechanism is that it doesn't guarantee that you are getting the most up-to-date version of the package (indeed, sometimes mirrors are slow to update). To help mitigate this problem, the signed release file includes a "Valid-Until" date after which all the files it references should be considered stale. It would be plausible for a man-in-the-middle to substitute an archive with an unmodified earlier version of the archive within this Valid-Until date and cause your APT to believe there are no updates. But they can't make any arbitrary modifications to packages nor could they go back in time past a certain point.

The signing mechanisms provide much better security than HTTPS in this kind of distributed environment where the files are mirrored over many servers not controlled by Ubuntu. In essence you only need to trust Ubuntu, not the mirror, so you need to prove that the files originally came from Ubuntu and have not been modified since - there's no need to verify the identity of the mirror.

Note that when you add a non-official repository to your sources list, such as a PPA, you will be receiving files that are not signed by Ubuntu. APT should warn you about this, because they haven't been signed by a certificate matching any of the public keys installed on your computer as authorised by Ubuntu.

15
  • 1
    Great! So the short version is "the transport layer is not secure, but each package is signed. There is no secure list of available updates and patches for existing security issues are not guaranteed to be delivered." Oct 3 '13 at 3:36
  • 2
    Not sure what you mean by "There is no secure list of available updates" but the release file and package lists are signed. It's just that it doesn't verify that your mirror is up to date. Oct 3 '13 at 6:08
  • 3
    Er, if there is no way to verify that a mirror, or the main site, is up to date then there is no way to know if there are updates available, security updates or otherwise. That is, there is no secure list of available updates. Oct 4 '13 at 3:30
  • 6
    Alice runs Ubuntu. Bob controls Alice's Internet connection. Bob cannot put a bad package into Alice's installation because each package is signed. There is some huge security flaw found in Ubuntu. Alice try's to find the updated package, but Bob removes all mention of the package from Alice's update check. Alice whacks a sysadmin and then pulls the update check via HTTPS from ubuntu.com verifying she is connected to the real website along a secure link. Now Alice sees the security update and Bob cannot hide it. Oct 6 '13 at 18:39
  • 4
    This is of course the correct answer. But what I find strange is that no one seems to be worried about an eavesdropper compiling a list of all the packages you have installed in order, including which ones you've updated and which ones you haven't, to target their attack on known security vulnerabilities in those packages.
    – Teekin
    Nov 28 '16 at 12:22
21

The top rated answer here is clearly outdated. Since then, there has been 2 serious remote code execution exploits found in apt because of buggy package verification. Security bulletins here and here.

This is much worse than the concerns about privacy/information leakage and stale package version; this enables arbitrary code execution as root, complete security failure. And the thing is: These attacks would have been prevented if https was used instead of http.

This proves that the defence in depth principle applies here as much as anywhere else. The many claims floating around that https provides no or minimal security benefit in the context of apt is simply incorrect, as has been shown by these exploits.

The question then becomes if the security benefit of https is worth the cost in terms of caching, increased overhead etc. I can't answer that, but at the very least I think Ubuntu/Canonical/Launchpad should provide optional https endpoints for their repositories.

4
  • 4
    Security is also about privacy, and HTTPS means will at the very least have a much harder time figuring out which packages and versions you are running.
    – l0b0
    Feb 21 '19 at 7:06
  • I'll say though that as long as apt itself isn't having problems with this, http is fine. However, https gives a backup in case the gpg security (or how it uses it more accurately) messes up. Feb 21 '19 at 10:13
  • I think, even if they try to be light on the transport volume and therefore expose the more massive downloads via http, at the very least the torrents and checksums/hashes (.md5, etc.) should be exposed securely via https. So that we had a means of verifying what we downloaded based on a reference obtained from a trusted source (identity). This seems all but safe as it is now ... :S
    – brezniczky
    Feb 9 '20 at 22:24
  • I am not too deeply into this, so please forgive any inaccuracies, but "someone else on the network can read or modify the website before you see it, putting you at risk" apparently is just unacceptable in case the result is an OS image. blog.mozilla.org/security/2017/01/20/…
    – brezniczky
    Feb 9 '20 at 22:30
10

All the files downloaded by APT have a signature that allows the downloaded file to be verified against the public keys stored on your computer as being signed by Ubuntu and only Ubuntu. This verifies that the file you receive was authorised by Ubuntu at some stage and hasn't been modified or tampered with since.

A technical explanation of how this works is available from Ubuntu (and from Debian which uses the same system).

Because of the use of HTTP instead of HTTPS, yes eavesdroppers could see what files you are downloading, but privacy is not likely to be your concern in this case. A man-in-the-middle attempt to modify the packages to inject harmful code would still fail because it would break the signing mechanism.

One possible gotcha in this signing mechanism is that it doesn't guarantee that you are getting the most up-to-date version of the package (indeed, sometimes mirrors are slow to update). To help mitigate this problem, the signed release file includes a "Valid-Until" date after which all the files it references should be considered stale. It would be plausible for a man-in-the-middle to substitute an archive with an unmodified earlier version of the archive within this Valid-Until date and cause your APT to believe there are no updates. But they can't make any arbitrary modifications to packages nor could they go back in time past a certain point.

The signing mechanisms provide much better security than HTTPS in this kind of distributed environment where the files are mirrored over many servers not controlled by Ubuntu. In essence you only need to trust Ubuntu, not the mirror, so you need to prove that the files originally came from Ubuntu and have not been modified since - there's no need to verify the identity of the mirror.

Note that when you add a non-official repository to your sources list, such as a PPA, you will be receiving files that are not signed by Ubuntu. APT should warn you about this, because they haven't been signed by a certificate matching any of the public keys installed on your computer as authorised by Ubuntu.

Source: Are repository lists secure? Is there an HTTPS version?

9
  • 4
    A few MitM attacks I can think of: replay an old list of software so that security patches don't get installed, observe what software is installed by which updated packages are downloaded or even which PPAs are subscribed to.
    – Olathe
    Mar 17 '16 at 23:02
  • When I try to hit archive.ubuntu.com/ubuntu, the connection is refused. It's as if they are not listening on the HTTPS port. Is there some other URL we're supposed to use for HTTPS?
    – smitelli
    Mar 22 '16 at 22:10
  • I was wrong, i cant get that to work either. That was Debian... I've adjusted the answer accordingly. BTW Follow the link and read the comments for more information! And please give credit to the writer.
    – Izzno
    Mar 23 '16 at 14:36
  • 1
    A more annoying bug is that when you apt update, apt doesn't seem to do any checking on the HTTP response coming from the server, and will overwrite your index cache with whatever bogus info. An attacker can be subtle and feed you a stale index, but an annoying attacker can just feed you random data and totally break your unattended config/install setups. The fix is to trash the index cache and run apt update again. Furthermore, if there's an exploit in the code that reads /var/lib/apt/lists, an attacker can MITM you an input that will exploit that code next time you run apt.
    – Marius
    Jun 20 '17 at 0:00
  • 9
    There are in fact multiple exploits of apt (1, 2) that allows arbitrary code execution as root that would have been prevented if https was used instead of http. This proves that the defence in depth principle applies here as much as anywhere else. The claim that https provides no or minimal security benefit is simply false. Jan 30 '19 at 8:11
3

Important supplement:in fact, as upgrade and initial installation download online, it takes a lot of traffic, and the source of these traffic, that is, binary and text code streams, is reproducible. So there are a large number of gateways and cache devices on the Internet for it. A considerable number of ISPs had set up cache based on the http protocol in order to save the export bandwidth, and the https protocol cannot exist as a transparent cache.

Another reason is that the http-based mirroring program is much simpler, there is no need to verify the tls-ssl certificate, and no need to worry about certificate invalidation or web server configuration problems too.

Not too long ago, about 20 years, at beginning of Internet, https and Internet traffic were still very expensive gameplays. Therefore, http also included the ftp protocol, which is close to being obsolete, as the main way of delivering installation and update for software packages distribution online.

Similarly, Microsoft Windows and Office are also upgraded using http. You can observe that it is usually not the installation package downloaded from the Microsoft's server, but your ISP's self-built cache server.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.