Ubuntu
apt package

Treats partial InRelease signature as verifying the entire file

Bug #784473 reported by William Grant on 2011-05-18

266

This bug affects 2 people

	Status	Importance	Assigned to
apt (Ubuntu)	Fix Released	Critical	Unassigned
Natty	Fix Released	Critical	Unassigned
Oneiric	Fix Released	Critical	Unassigned

Bug Description

Binary package hint: apt

apt's inline signature verification for InRelease is broken: it treats any signature in the file as validating the whole file. It's also fairly liberal when parsing the content of such files, apparently ignoring everything after the first blank line.

Combined, these two behaviours allow an attacker to turn an arbitrary Release file into a valid, signed InRelease file by appending a blank line and a valid inline signed message from a trusted key. I've tested by appending http://ftp.debian.org/debian/dists/experimental/InRelease, as Ubuntu's archive key does not clearsign anything that I can find, and line-ending canonicalisation thwarted my attempts at converting a detached signature into a cleartext one.

Related branches

lp:~ubuntu-core-dev/apt/ubuntu

lp:ubuntu/oneiric/apt

lp:ubuntu/natty-security/apt

lp:~mvo/apt/debian-sid (Merged)

CVE References

2011-1829

Michael Vogt (mvo) on 2011-05-23

Changed in apt (Ubuntu):
status:	New → Confirmed
importance:	Undecided → Critical

Revision history for this message

Michael Vogt (mvo) wrote on 2011-05-24:

ubuntu-bug-784473-InRelease-one-message-only.diff Edit (2.7 KiB, text/plain)

David was kind enough to provide a patch for this bug.

Apt will now ensure that the InRelease file starts with a "-----BEGIN PGP SIGNED MESSAGE-----" header.

Apt already discards everything after the second ^---- line in a InRelease file. So this ensures that only the part between
header line and tail is used. The way I read rfc2440 is that we can be sure that gpgv checks this message. This still allows adding
junk after the tail pgp lines, but that does not matter as apt discards it. Ideally we would use gpg --output, but unfortunately gpgv does not provide this option.

Alternatively we could simply disable InRelease entirely in natty (its not used currently by ubuntu).

Revision history for this message

Kees Cook (kees) wrote on 2011-05-25:

CVE-2011-1829

Revision history for this message

Marc Deslauriers (mdeslaur) wrote on 2011-06-28:

Looks like support for InRelease files isn't in maverick, but is in Natty...

Changed in apt (Ubuntu Natty):
status:	New → Confirmed
importance:	Undecided → Critical

Revision history for this message

Marc Deslauriers (mdeslaur) wrote on 2011-07-06:

Email was sent out with a proposed CRD of <2011-07-13 17:00 UTC>.

Revision history for this message

Launchpad Janitor (janitor) wrote on 2011-07-13:

This bug was fixed in the package apt - 0.8.15.1ubuntu2

---------------
apt (0.8.15.1ubuntu2) oneiric; urgency=low

  [ Brian Murray ]
  * apt-pkg/deb/dpkgpm.cc:
   - do not report errors encountered when decompressing packages

  [ Michael Vogt ]
  * fix from David Kalnischkies for the InRelease gpg verification
    code (LP: #784473)
-- Michael Vogt <email address hidden> Wed, 13 Jul 2011 14:42:02 +0200

Changed in apt (Ubuntu Oneiric):
status:	Confirmed → Fix Released

Revision history for this message

Launchpad Janitor (janitor) wrote on 2011-07-13:

This bug was fixed in the package apt - 0.8.13.2ubuntu4.1

---------------
apt (0.8.13.2ubuntu4.1) natty-security; urgency=low

  * SECURITY UPDATE: incorrect InRelease file signature validation
    (LP: #784473)
    - apt-pkg/indexcopy.cc, methods/gpgv.cc: Ensure file starts with
      clearsigned message header.
    - patch thanks to David Kalnischkies.
    - CVE-2011-1829
-- Marc Deslauriers <email address hidden> Thu, 07 Jul 2011 08:20:46 -0400

Changed in apt (Ubuntu Natty):
status:	Confirmed → Fix Released

Marc Deslauriers (mdeslaur) on 2011-07-28

visibility:

private → public

Revision history for this message

Jason Gunthorpe (jgunthorpe) wrote on 2011-08-11:

You really need to use --output to process inline signatures, trying to exactly match what gnupg validated externally is not a robust way to run such important crypto. It would be better to require full gpg until gpgv can be fixed - (not having --output in gpgv only encourages incorrect use of the program!).