Updating is over insecure connection

Bug #1186793 reported by Colin O'Brien
292
This bug affects 8 people
Affects Status Importance Assigned to Milestone
Ubuntu
Confirmed
Undecided
Unassigned

Bug Description

Relying on signatures is silly. It gives attackers much more control over a situation, and we already know that this *doesn't work* when weak signatures like MD5 are used (see Flame hash collision). Is the average user going to get attacked this way, with a collision? Maybe not. But Ubuntu servers are going to get targeted, and updating over HTTP just doesn't make sense.

Flame may have been a government attack aimed at other governments, but users were infected. They were attacked to get to the government systems. So whether you're a server or a high value target or whatever, there are people who will try to exploit this system. Preventing this is as simple as properly implementing HTTPS and encouraging third party developers to do the same with their packages..

https://www.cs.arizona.edu/stork/packagemanagersecurity/

https://en.wikipedia.org/wiki/Flame_(malware)#Operation

HTTPS with HSTS in particular will prevent:

1) An attacker from viewing traffic that can give them information as to the attack surface on a system. They can see which applications are at which versions, and how often the system is updating.

2) It means that if the signing key is compromised the attacker can install their own updates via MITM.

HTTPS prevents this.

Is there any solid reason why updates are still over an insecure connection? Microsoft has updated over a secure connection for a year now.

The equivalent for the initial Ubuntu download is bug 1359836.

This bug was featured on HTTP Shaming. <http://httpshaming.tumblr.com/post/95198336486/ubuntu-appears-to-retrieve-packages-and-details-on>

Tags: bot-comment
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in ubuntu:
status: New → Confirmed
Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1186793/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

tags: added: bot-comment
Revision history for this message
Colin O'Brien (insanitybit) wrote :

I tried assigning ia32-apt-get but it says it isn't a package in Ubuntu.

Revision history for this message
Chris Thompson (chris-j-thompson) wrote :

The linked bug is not a duplicate of this one. That bug was for the replay and endless data attacks posed in the Stork work. This bug is that the repositories are not served over HTTPS, which is another issue that the Stork work pointed out.

Revision history for this message
Colin O'Brien (insanitybit) wrote :

Like Chris Thompson said, completely different bug report. Not a duplicate.

Revision history for this message
Matthew Paul Thomas (mpt) wrote :

Fixing this might depend on bug 1185159 and/or bug 1209292.

description: updated
information type: Public → Public Security
Revision history for this message
Matthew Paul Thomas (mpt) wrote :

This requires more than just switching to HTTPS. The updates UI will also need to explain HTTPS failures in such a way that users don't seek insecure workarounds.

Windows updates are being subjected to MITM patches. Windows Update correctly fails to install them, but gives a vague error code. Googling for a solution to the problem leads people to a direct download that is not subject to the same security checking and can therefore be MITMed successfully. <http://www.leviathansecurity.com/blog/the-case-of-the-modified-binaries/>

Discouraging people from bypassing HTTPS errors is a problem also faced by browser designers.
<http://blog.johnath.com/2008/11/06/ssl-error-pages-in-firefox-31/>
<http://webscripts.softpedia.com/blog/Chrome-s-New-SSL-Error-Pages-393600.shtml>

Revision history for this message
Dimitri John Ledkov (xnox) wrote :

= Updates =

Ubuntu downloads updates over http by default, however that is not insecure. This is because all those updates are validated with GPG against the keys that are already on the system in the ubuntu-keyring package.

The signatures on our updates are strong, bashed on SHA512 checksums at the moment.

It is signed at the moment by two keys, as we are still in a transition period - 1024 dsa key and 4096 rsa key.
See for yourself at:
http://archive.ubuntu.com/ubuntu/dists/xenial/InRelease

And that key is part of the strong set of trusted GPG keys. E.g. I am lucky enough to have a trust path to those keys via James Troup and Steve Langasek. But I find that much stronger than to arbitrary trust all SSL certs for example.

Switching to SSL is a knee-jerk reaction, which is not really appropriate for a mirrored update server. First of all, we must support for people to create a private mirror of Ubuntu on internal networks to update their internal infrastructure. And on the other hand we may not trust all SSL certificates from all the authorities either (because then a rogue CA will be able to misrepresent an update server). This means that if we were to rely on SSL, we would have to use certificate pinning to only ever trust a single certificate, thus making the overall security solution less reliable than the current secure GnuPG protected updates.

Also note, the security track record of GnuPG signing and validation, is far better to date than SSL/TLS across multiple implementations of both server and client sides.

= Initial installation =
Granted the initial ubuntu-keyring package is installed on the system from somewhere. It typically comes from an .iso image which the person downloads and installs. To be prudent, one should verify the SHA checksums of the .iso images, and the gpg signatures of those checksums, thus validating that the image has in fact originated from Ubuntu by means of the GnuPG web of trust.

e.g.
http://releases.ubuntu.com/trusty/SHA256SUMS
http://releases.ubuntu.com/trusty/SHA256SUMS.gpg

= End note =
Ubuntu does not use MD5 as the only, nor as default checksuming. It is not used to generate signatures. Please note that SSL, TLS, and GnuPG are all types of cryptographic signatures. Thus I'm not sure what you mean by some of your statements.

Overall we protect the content, rather than the protocol. And thus support CDN distribution, global mirroring network and country mirrors. Unlike TLS, the encryption key does not participate in establishing the connection, and thus is maintained offline. Avoiding a class of problems with leaking key material as has been demonstrated with TLS and heart-bleed vulnerability.

The privacy issue is not addressed, this is true. However this alone does not undermine the security and authenticity of Ubuntu update process.

Revision history for this message
Dimitri John Ledkov (xnox) wrote :

We do not provide a default way to receive updates in a private manner. However, one can arrange private methods of doing so. Create an ubuntu mirror via an out-of-bound connection and point your machines there, thus not exposing update traffic to a monitored connection.

After establishing an out-of-bound mirror, you may even wish to publish it over SSL. Which is totally valid, and supported by all Ubuntu installations that have apt-transport-https package installed.

Revision history for this message
Dimitri John Ledkov (xnox) wrote :

Please let me know if you have further concerns.

Changed in ubuntu:
status: Confirmed → Incomplete
Revision history for this message
Aminda Suomalainen (mikaela) wrote :

How do gpg signatures and SHA512 sums help with other people in the open WLAN or between I and the mirror being able to see what exactly I download or update?

Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for Ubuntu because there has been no activity for 60 days.]

Changed in ubuntu:
status: Incomplete → Expired
Revision history for this message
Robie Basak (racb) wrote :

> How do gpg signatures and SHA512 sums help with other people in the open WLAN or between I and the mirror being able to see what exactly I download or update?

HTTPS wouldn't protect you either. The sizes and dependency trees of individual packages are well-known. If I could see your HTTPS apt download traffic, I'd also be able to infer exactly what you downloaded or updated.

Revision history for this message
Marco Voelz (marco-voelz) wrote :

Any thoughts on https://blog.packagecloud.io/eng/2018/02/21/attacks-against-secure-apt-repositories/ ?
Seems like there are a few good reasons to using TLS, wdyt?

Andy Brody (abrody)
Changed in ubuntu:
status: Expired → Confirmed
Revision history for this message
Brian Foster (blfoster) wrote (last edit ):

I'm also not massively happy about the use of HTTP rather then HTTPS, albeit (in my opinion) the issue is *not* so much “other people […] being able to see what exactly I download or update?” Whilst I'm not thrilled with that, that issue is *not* a concern in my Risk Analysis.

Instead, I am bothered by what seems to be a lack of “orthogonal barriers”, or more precisely, the checks on the integrity of the downloaded updates is entirely(?) GPG-based. Should there be a problem — with GPG itself (or its installation (which isn't necessarily from Ubuntu, albeit that is presumably unusual)), with the relevant Keys, etc — than the integrity (non-corruption, etc.) assurances may be questionable.

The use of HTTPS does not “solve” all those concerns (not to mention the issues raised by by the report cited in #14), but it should add an additional layer of assurance, somewhat orthoganal (i.e., independent-of) the GPG-signing mechanism.

Other (non-Canonical) repositories _do_ use / allow HTTPS; e.g., from a recent update of mine:

   $ sudo apt-get update
   Hit:1 http://security.ubuntu.com/ubuntu jammy-security InRelease
   Hit:2 http://[REDACTED].archive.ubuntu.com/ubuntu jammy InRelease
   Hit:3 http://[REDACTED].archive.ubuntu.com/ubuntu jammy-updates InRelease
 ▶ Hit:4 https://brave-browser-apt-release.s3.brave.com stable InRelease
   Hit:5 http://[REDACTED].archive.ubuntu.com/ubuntu jammy-backports InRelease
 ▶ Hit:6 https://repo.protonvpn.com/debian stable InRelease
  …

Note that two “security-conscience” repositories — ▶ ProtonVPN and Brave — do use HTTPS, obviously(? presumably?) in addition to GPG-signing, etc.

Please note I have not (yet?) tried manually editing the relevant file(s?) to use HTTPS, since in the past manual-edits have not worked too well (for me). (A huge Thank You to etckeeper(8) for allowing me to easily test / roll-back changes within /etc !)

Revision history for this message
Brian Foster (blfoster) wrote :
Download full text (5.1 KiB)

(Update to my #15, above…)
Modifying /etc/apt/sources.list to use HTTPS exclusively (see diff below) resulted in:

   # sudo apt-get update
   Hit:1 https://brave-browser-apt-release.s3.brave.com stable InRelease
   Hit:2 https://repo.protonvpn.com/debian stable InRelease
 ▷ Ign:3 https://security.ubuntu.com/ubuntu jammy-security InRelease
   Hit:4 https://[REDACTED].archive.ubuntu.com/ubuntu jammy InRelease
   Hit:5 https://[REDACTED].archive.ubuntu.com/ubuntu jammy-updates InRelease
   Hit:6 https://[REDACTED].archive.ubuntu.com/ubuntu jammy-backports InRelease
 ▷ Ign:3 https://security.ubuntu.com/ubuntu jammy-security InRelease
 ▷ Ign:3 https://security.ubuntu.com/ubuntu jammy-security InRelease
 ▶ Err:3 https://security.ubuntu.com/ubuntu jammy-security InRelease
     Could not handshake: Error in the pull function. [IP: 91.189.91.39 443]
  …

That _seems_ to indicate (partial) success, albeit the “Ign”s (▷) are concerning. And there is an “Err” (▶), which is very Very concerning. whois(1) reports 91.189.91.39 belongs to Canonical.

From GIT / etckeeper(8):

   # cd /etc
   # git diff
   diff --git a/apt/sources.list b/apt/sources.list
   index 81ada6e..5bd8f18 100644
   --- a/apt/sources.list
   +++ b/apt/sources.list
   @@ -2,43 +2,43 @@
  … [REDACTED #comments]
   -# See http://help.ubuntu.com/community/UpgradeNotes for how to upgrade to
   +# See https://help.ubuntu.com/community/UpgradeNotes for how to upgrade to
    # newer versions of the distribution.
   -deb http://[REDACTED].archive.ubuntu.com/ubuntu/ jammy main restricted
   -deb-src http://[REDACTED].archive.ubuntu.com/ubuntu/ jammy multiverse universe main restricted #Added by software-properties
   +deb https://[REDACTED].archive.ubuntu.com/ubuntu/ jammy main restricted
   +deb-src https://[REDACTED].archive.ubuntu.com/ubuntu/ jammy multiverse universe main restricted #Added by software-properties

    ## Major bug fix updates produced after the final release of the
    ## distribution.
   -deb http://[REDACTED].archive.ubuntu.com/ubuntu/ jammy-updates main restricted
   -deb-src http://[REDACTED].archive.ubuntu.com/ubuntu/ jammy-updates multiverse universe main restricted #Added by software-properties
   +deb https://[REDACTED].archive.ubuntu.com/ubuntu/ jammy-updates main restricted
   +deb-src https://[REDACTED].archive.ubuntu.com/ubuntu/ jammy-updates multiverse universe main restricted #Added by software-properties

    ## N.B. software [REDACTED]om this repository is ENTIRELY UNSUPPORTED by the Ubuntu
    ## team. Also, please note that software in universe WILL NOT receive any
    ## review or updates [REDACTED]om the Ubuntu security team.
   -deb http://[REDACTED].archive.ubuntu.com/ubuntu/ jammy universe
   -deb http://[REDACTED].archive.ubuntu.com/ubuntu/ jammy-updates universe
   +deb https://[REDACTED].archive.ubuntu.com/ubuntu/ jammy universe
   +deb https://[REDACTED].archive.ubuntu.com/ubuntu/ jammy-updates universe

    ## N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu
    ## team, and may not be under a free licence. Please satisfy yourself as to
    ## your rights to use the software. Also, please note that software ...

Read more...

To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.