1024-bit signing keys should be deprecated

Bug #1461834 reported by deutrino
320
This bug affects 14 people
Affects Status Importance Assigned to Milestone
Launchpad itself
New
Undecided
Unassigned
apt (Ubuntu)
Invalid
Undecided
Unassigned
gnupg2 (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

1024-bit RSA was deprecated years ago by NIST[1], Microsoft[2] and more recently by others[3].

1024-bit signing keys are insufficient to guarantee the authenticity of software distributed from Launchpad.net including PPAs. There should be a mechanism to refuse signing keys below a minimum key length based on key type. 1024-bit signing keys should be deprecated and removed from Launchpad.net itself ASAP. Future projects and PPAs should be disallowed from using 1024-bit signing keys.

1. http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf
2. http://blogs.technet.com/b/pki/archive/2012/06/12/rsa-keys-under-1024-bits-are-blocked.aspx
3. https://threatpost.com/mozilla-1024-bit-cert-deprecation-leaves-107000-sites-untrusted/108114

deutrino (deutrino)
information type: Private Security → Public Security
description: updated
Revision history for this message
Micah Lee (micahflee) wrote :

+1, I agree that this is very important.

Revision history for this message
Patrik B. (inoki-deactivatedaccount) wrote :

Agreed and supporting the idea. +1

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

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

Changed in apt (Ubuntu):
status: New → Confirmed
Revision history for this message
Seth Arnold (seth-arnold) wrote :

It might be nice if apt could be configured with "minimum accepted algorithms" or "required algorithms", to allow administrators to require e.g. sha256 or sha3 or blake2b, or rsa 4096 or ed25519, etc.

Revision history for this message
William Grant (wgrant) wrote :

Launchpad has used 4096-bit RSA keys for new PPAs since bug #1240681 was fixed. Allowing PPA owners to replace the old 1024-bit keys is bug #1331914.

no longer affects: launchpad
Revision history for this message
deutrino (deutrino) wrote :

I disagree with the "no longer affects" Launchpad. This is a matter of policy and as such very definitely DOES affect Launchpad, regardless of the resolution of bug #1331914.

Bob Freeman (bobfreeman)
tags: added: encryption needs-update security vulnerability
Revision history for this message
Bob Freeman (bobfreeman) wrote :

Updates usually run automatically in the background, including from PPAs, and are unencrypted. This means a man-in-the-middle can gain root access, just by inserting their own version of one of the packages into this network traffic, because updates run as root. They can first obtain the public 1024 bit key from the PPA, then spend as long as they want working out the private key, then sign their false updates with the real private key.

A bug that allows complete compromise of most Ubuntu machines without requiring any user involvement is a very serious bug. Why hasn't this even been assigned to anyone, nearly 2 years after it was reported?

This makes many PPAs unusable.

https://en.wikipedia.org/wiki/Key_size#Asymmetric_algorithm_key_lengths
'RSA claims that 1024-bit keys are likely to become crackable some time between 2006 and 2010'
https://www.symantec.com/page.jsp?id=1024-bit-migration-faq#issue
In compliance with Certification Authority/Browser forum requirements based on NIST Special Publication 800-131A, at the end of 2013 all web browsers and Certification Authorities (CAs) will no longer sell or support 1024-bit RSA certificates. All certificates less than 2048-bit key length will need to be revoked and replaced with certificates with a higher encryption strength.

Network connections are secured with at least 2048 bits. Installing software allows root access and should probably be secured with at least 4096 bits.

Any system using keys has to have a way to change to a new key, that's a basic requirement.
You could force all 1024 bit keys to 4096 bits - this might break existing updates, but they are already 'broken' by being vulnerable. Or sign with 2 keys, so a new subscriber will only use the newer one, but old subscribers who don't do anything about it will still use the old key. Or re-issue the entire PPA namespace, ie ppa2:... Or do some other such thing, eg update the client to include a newer protocol version number in its requests.

A simple workaround for launchpad to apply would be to change the urls in files in /etc/apt/sources.list.d/ to use https://ppa.launchpad.net/ instead of http://ppa.launchpad.net/ (and change the server to support it). This would only need to be done for any PPA still using a 1024 bit key. Then at least the packages would be authenticated by TLS, which already uses 2048 bit keys.

Revision history for this message
Bob Freeman (bobfreeman) wrote :

Launchpad could *automatically* create a mirror of any PPA that still uses a 1024 bit key, with a standard suffix to the name, eg xyzppa gets mirrored as xyzppa-newkey. It could then link to it from the page for the original PPA. It would always have all the same source, built files and other content, and the content would only need to be stored once on the server. It would just be a different way of accessing the same PPA.

Revision history for this message
deutrino (deutrino) wrote :

> This means a man-in-the-middle can gain root access, just by inserting their own version of one of the packages into this network traffic, because updates run as root. They can first obtain the public 1024 bit key from the PPA, then spend as long as they want working out the private key, then sign their false updates with the real private key.
>
> A bug that allows complete compromise of most Ubuntu machines without requiring any user involvement is a very serious bug. Why hasn't this even been assigned to anyone, nearly 2 years after it was reported?

I suppose people will be wondering why it wasn't fixed once a Snowden-style leak drops showing that this vulnerability was exploited for years.

Revision history for this message
Julian Andres Klode (juliank) wrote :

APT currently rejects all non-SHA2 hashes, which excludes 1024 bit DSA keys (the only 1024 bit keys in use, really). All repositories were told to update to 2048 or 4096 bit RSA keys.

GPG does not provide a way for APT to validate key lengths when the signature is verified, so we did all we could do here. Any future change needs to be made in gpg (reject all DSA/RSA keys less than 2048 bit).

Changed in apt (Ubuntu):
status: Confirmed → Invalid
Revision history for this message
Julian Andres Klode (juliank) wrote :

Side note: It's incredibly funny how the bug report talks about 1024 bit RSA keys, when such keys have likely never been used by anyone (all 1024 bit keys I know about were DSA).

Revision history for this message
Julian Andres Klode (juliank) wrote :

Regarding launchpad: I'm not sure what that bug is achieving. The proposal with the rename is fairly useless, you could just add the safe key to the existing repository. The biggest problem in practice is rolling out a new key to users, as there is no mechanism for that.

Revision history for this message
Colin Watson (cjwatson) wrote :

Julian, I'm afraid that for better or worse Launchpad did generate 1024-bit RSA keys for PPAs for quite some time, and that wasn't an entirely silly decision back when it was first made - even then DSA had known weaknesses. It's a problem, but as you say we'd need to work out a rollover mechanism. Signing with two keys is certainly a possibility (we did that with the Ubuntu archive for a while, so it's battle-tested), and I expect that any solution to this would involve that, but there's no clear way to end the transition.

Bob, I'm afraid that your proposed "simple" workaround is no such thing (a naive implementation would expose launchpad.net to XSS attacks from user-supplied content on ppa.launchpad.net). I listed the issues that would need to be solved in bug 1473091. Anyway, TLS is a side issue here and this bug shouldn't be derailed into that.

We are very unlikely to do any of the proposed renaming/mirroring hacks; they would be a mess and likely a cure worse than the disease.

Revision history for this message
Bob Freeman (bobfreeman) wrote :

Sign with two keys then, and try to tell people. After a period of time you could disable the old key (ie no longer sign anything with it) - for anyone who still hasn't updated their configuration their system will still work, but instead of updates they would get errors. Then they would update their config.

(Note that all PPA packages are already available through TLS, eg https://launchpad.net/~fnu/+archive/ubuntu/main-fnu/+build/8797131/+files/cmake-qt-gui_2.8.12.2-3_amd64.deb but only for manual download. It is not used automatically by apt, so to be secure you have to identify and manually download a lot of packages. These can be found through the 'View package details' link at the top right on all PPA main pages)

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

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

Changed in gnupg2 (Ubuntu):
status: New → Confirmed
Changed in apt (Ubuntu):
status: Invalid → Confirmed
Changed in launchpad:
status: New → Confirmed
assignee: nobody → wachirapranee tesprasit (tatar28)
Changed in apt (Ubuntu):
assignee: nobody → wachirapranee tesprasit (tatar28)
Changed in gnupg2 (Ubuntu):
assignee: nobody → wachirapranee tesprasit (tatar28)
Changed in launchpad:
status: Confirmed → Fix Released
Changed in apt (Ubuntu):
status: Confirmed → Fix Released
Changed in gnupg2 (Ubuntu):
status: Confirmed → Fix Released
description: updated
Colin Watson (cjwatson)
description: updated
Changed in launchpad:
assignee: wachirapranee tesprasit (tatar28) → nobody
Changed in apt (Ubuntu):
assignee: wachirapranee tesprasit (tatar28) → nobody
Changed in gnupg2 (Ubuntu):
assignee: wachirapranee tesprasit (tatar28) → nobody
Changed in launchpad:
status: Fix Released → New
Changed in apt (Ubuntu):
status: Fix Released → Invalid
Changed in gnupg2 (Ubuntu):
status: Fix Released → Confirmed
Revision history for this message
Bob Freeman (bobfreeman) wrote :

> GPG does not provide a way for APT to validate key lengths when the signature is verified, so we did all we could do here.

Some pages, like https://launchpad.net/~fnu/+archive/ubuntu/main-fnu/ say "Signing key: 1024R" when you click on "Technical details about this PPA". So launchpad clearly knows, and at the very least it *must* put a big warning on such pages, so as not to fool users into compromising the security of their computers. It's not true to say there's nothing launchpad can do.

Since the underlying problem is clearly real, why is this launchpad bug still 'New' and not 'Confirmed' after more than 6 years 2 months?

Revision history for this message
Martin (c0rn3j) wrote (last edit ):

Why is this still a thing, nearly a decade after NIST disallowed the usage? [1]

Why is it not possible for users to regenerate their signing keys? [2]

What if someone believes their key is compromised? Do they have to burn their work and create an entirely new page and direct their users there?

What if someone created a key with RSA 1024 and would like to migrate it to a secure variant? Looks like they can't. [2]

And it shows, because even very popular PPAs like ondrej/php are using RSA1024 keys from 2009, and it does not look to be their fault. [3]

[1] https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/announcements/2013-announcements
[2] https://bugs.launchpad.net/launchpad/+bug/1331914
[3] https://github.com/oerdnj/deb.sury.org/issues/1429#issuecomment-656190271

Revision history for this message
Julian Andres Klode (juliank) wrote :

What I'd like to see is that

1. launchpad starts dual-signing repositories
2. ubuntu-release-upgrader gets a quirk that replaces any unsafe PPA keys on upgrade to kinetic+ (jammy backport possible too, but arguably people might have already upgraded)
3. Drop 1024 bit keys for kinetic+

This will lead to everyone running kinetic and newer to at least use RSA keys.

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.