[Bug 1330770] [NEW] click packages rely upon tls for integrity and authenticity

[Seth Arnold]

*** This bug is a security vulnerability ***

Public security bug reported:

Hello, I just completed a quick review of the click source and the
unity-scope-click source and behaviours, and found some opportunities
for improvement.

Debian, and Ubuntu, rely upon signed repository files with cryptographic
hashes of packages to provide both integrity and authenticity checks for
the packages hosted on that repository.

The click framework and the unity-scope-click discovery and installation
tool do not use signed repository files, nor do they have signatures of
any sort on downloaded packages. The only integrity and authenticity
checks are provided by the use of HTTPS.  The click verify command will
check files within the archive against MD5sums stored inside the archive
but the click verify command is not used during package installation.
(This is suitable for validating integrity against accidental changes
only.)

While it appears that unity-scope-click properly uses HTTPS to download
package metadata and packages, HTTPS alone is insufficient for our
needs:

- Someone in a position to create new certificates at any of several
hundred certificate authorities could create certificates purporting to
be our update servers. This actual problem has been discovered in the
wild with several certificate authorities issuing wild-card certificates
or even certificates with signing authority.

- X.509 is extremely complicated; TLS is extremely complicated. Flaws in
both are inevitable.

- HTTPS prevents the use of caching.

- HTTPS only 'works' for data-in-motion; it is useless for data-at-rest
integrity and authenticity checks.

I have not yet reviewed the tools that application authors will use to
upload their packages to our distribution servers but note in passing
that most of these issues are also issues for adding packages to our
update servers -- packages in flight within our network can be corrupted
for many reasons, packages on disk can be corrupted for many reasons. A
signature mechanism can protect against internal network faults, storage
faults, and provide assurance months or years later that an uploaded
package was uploaded by someone in control of a corresponding private
key.

Thanks

** Affects: click (Ubuntu)
     Importance: Undecided
         Status: New

** Affects: unity-scope-click (Ubuntu)
     Importance: Undecided
         Status: New

** Also affects: unity-scope-click (Ubuntu)
   Importance: Undecided
       Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to click in Ubuntu.
https://bugs.launchpad.net/bugs/1330770

Title:
  click packages rely upon tls for integrity and authenticity

Status in “click” package in Ubuntu:
  New
Status in “unity-scope-click” package in Ubuntu:
  New

Bug description:
  Hello, I just completed a quick review of the click source and the
  unity-scope-click source and behaviours, and found some opportunities
  for improvement.

  Debian, and Ubuntu, rely upon signed repository files with
  cryptographic hashes of packages to provide both integrity and
  authenticity checks for the packages hosted on that repository.

  The click framework and the unity-scope-click discovery and
  installation tool do not use signed repository files, nor do they have
  signatures of any sort on downloaded packages. The only integrity and
  authenticity checks are provided by the use of HTTPS.  The click
  verify command will check files within the archive against MD5sums
  stored inside the archive but the click verify command is not used
  during package installation. (This is suitable for validating
  integrity against accidental changes only.)

  While it appears that unity-scope-click properly uses HTTPS to
  download package metadata and packages, HTTPS alone is insufficient
  for our needs:

  - Someone in a position to create new certificates at any of several
  hundred certificate authorities could create certificates purporting
  to be our update servers. This actual problem has been discovered in
  the wild with several certificate authorities issuing wild-card
  certificates or even certificates with signing authority.

  - X.509 is extremely complicated; TLS is extremely complicated. Flaws
  in both are inevitable.

  - HTTPS prevents the use of caching.

  - HTTPS only 'works' for data-in-motion; it is useless for data-at-
  rest integrity and authenticity checks.

  I have not yet reviewed the tools that application authors will use to
  upload their packages to our distribution servers but note in passing
  that most of these issues are also issues for adding packages to our
  update servers -- packages in flight within our network can be
  corrupted for many reasons, packages on disk can be corrupted for many
  reasons. A signature mechanism can protect against internal network
  faults, storage faults, and provide assurance months or years later
  that an uploaded package was uploaded by someone in control of a
  corresponding private key.

  Thanks

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/click/+bug/1330770/+subscriptions