click packages rely upon tls for integrity and authenticity

[Seth Arnold]

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

[Ricardo Kirkner (ricardokirkner)]

Have we already defined what specific signature mechanism we want/need to implement server side? As far as I understand this we'll need the following

1. Upon upload of the click package, we compute a signature for it (what type of signature?)
2. We expose the computed signature somewhere public so that the click installer can compare it with it's own computation before installing the package.

Please add any particular specifics we should consider when implementing this.

[Marc Deslauriers (mdeslaur)]

I plan on creating a wiki page with the whole thing detailed out later this week.

[Ricardo Kirkner (ricardokirkner)]

Ack. Thanks

On Mon, Jun 23, 2014 at 12:13 PM, Marc Deslauriers <
<email address hidden>> wrote:

> I plan on creating a wiki page with the whole thing detailed out later
> this week.
>
> --
> You received this bug notification because you are a member of Buy-
> something hackers, which is subscribed to Software Center Agent.
> https://bugs.launchpad.net/bugs/1330770
>
> Title:
> click packages rely upon tls for integrity and authenticity
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/software-center-agent/+bug/1330770/+subscriptions
>

[Colin Watson (cjwatson)]

https://lists.launchpad.net/ubuntu-appstore-developers/msg00394.html

[Ricardo Kirkner (ricardokirkner)]

A few more questions to consider:

1. do we also want to generate (and expose) signatures for source uploads, or just the binary files?
2. since we're exposing the computed signature for verification purposes, we need to document how to recompute the signature on the device itself, correct?

[Marc Deslauriers (mdeslaur)]

Here's the basic outline of how I think we should do this:

https://wiki.ubuntu.com/SecurityTeam/Specifications/ClickPackageSigning

Once everyone agrees to the approach, I can add details if needed.

[Alejandro J. Cura (alecu)]

On Fri, Jun 27, 2014 at 9:30 AM, Marc Deslauriers
<email address hidden> wrote:
> Here's the basic outline of how I think we should do this:
>
> https://wiki.ubuntu.com/SecurityTeam/Specifications/ClickPackageSigning

Hi Marc, thanks for working on this.

I agree with the general approach.

I've made a few edits[1] to those steps because the download manager
queues all downloads and the click scope may be dead at the time
downloads are completed. But when starting a download, you can pass a
command line to download manager and it gets run when the download is
completed. So the click scope installs a small script called
"install-helper" that calls packagekit and refreshes the dash with the
new icons when the installation succeeds.

So, to include signatures, it should be the click scope the one
skipping the queue and downloading the detached signature and
verifying its sha-512. And it should pass the path of the signature as
a parameter of the command line for install helper that gets passed to
download manager, and install helper should use it to call packagekit.

[1] My edits are here:
https://wiki.ubuntu.com/SecurityTeam/Specifications/ClickPackageSigning?action=diff&rev1=2&rev2=3

cheers,
--
alecu

[Alejandro J. Cura (alecu)]

The code doing app updates in system settings will also need to do the same steps as the click scope:
- download the signatures
- do the sha-512 verification
- and pass them to packagekit.

[Alejandro J. Cura (alecu)]

A correction to comment #8, after the latest changes in the spec:

The code doing app updates in system settings will also need to do the same steps as the click scope:
- fetch the sha-512 hash from the package details webservice
- pass it to download manager so it can verify the download of the package with the store signature appended.

There's no longer a need for the updater nor the click scope to download signatures nor to pass them to packagekit.

[PS Jenkins bot (ps-jenkins)]

Fix committed into lp:unity-scope-click/devel at revision None, scheduled for release in unity-scope-click, milestone Unknown

[Launchpad Janitor (janitor)]

This bug was fixed in the package unity-scope-click - 0.1.1+14.10.20140821.1-0ubuntu1

---------------
unity-scope-click (0.1.1+14.10.20140821.1-0ubuntu1) utopic; urgency=medium

  [ Alejandro J. Cura (alecu) ]
  * New upstream release.
    - Display Ubuntu logo in the header of apps scope. (LP: #1350610)
    - Pass the sha512 hash from the details webservice to download manager.
      (LP: #1330770)
    - Sort departments alphabetically. (LP: #1354044)
    - Exclude empty departments from the departments tree in Apps.
      (LP: #1350609)
    - Provide updated departments to match latest server changes. Bumped
      schema to 3.
    - New script to enable purchases in the scope during beta. (LP: #1356419)
    - Add dependency on libglib2.0-bin and upstart-bin for script above.
    - Enable QNetworkDiskCache for http GET requests. (LP: #1351212)
    - Query download manager for in-progress downloads. (LP: #1234965)
    - Only show extended info for apps from the store. (LP: #1350571)
    - Don't expand categories by default in the store. (LP: #1355221)
    - Do not use static const strings for translations. (LP: #1354501)
    - Change "All departments" to just "All". (LP: #1351536)
    - Localize the extra department title in the store. (LP: #1358790)
    - Updated translations.

  [ Martin Pitt ]
  * Mark for using language packs.

  [ Ubuntu daily release ]
  * New rebuild forced
 -- Ubuntu daily release <email address hidden> Thu, 21 Aug 2014 20:40:59 +0000

[Launchpad Janitor (janitor)]

This bug was fixed in the package click - 0.4.31.2

---------------
click (0.4.31.2) utopic; urgency=medium

  [ Michael Vogt ]
  * Add "click info" interface to get manifest corresponding to file in
    installed package (LP: #1324853).
  * Add support for click package gpg signatures (LP: #1330770).

  [ Colin Watson ]
  * Ugly hack to get coverage reporting working again with gcovr 3.1.

  [ Ubuntu daily release ]
  * New rebuild forced
 -- Ubuntu daily release <email address hidden> Fri, 22 Aug 2014 17:19:06 +0000

[Jamie Strandboge (jdstrand)]

I see an ubuntu-system-settings task and was wondering what it is for? The spec (https://wiki.ubuntu.com/SecurityTeam/Specifications/ClickPackageSigning) says: "Configuring the system to allow installing unsigned packages should not be exposed via the UI and only available via the command line/adb". Should this task be removed?

[Alejandro J. Cura (alecu)]

The main task in ubuntu-system-settings for this bug is about app updates: the code doing the updates fetches the url for the click package from a webservice, and passes that url to ubuntu-download-manager. What's missing is fetching also the sha512 hash from the same webservice call, and passing it to ubuntu-download-manager to do the verification after download.

[Alejandro J. Cura (alecu)]

I've set this to Critical, because it will affect every user doing updates of any app.

[Pat McGowan (pat-mcgowan)]

seb were you handling this one?

[Michael Vogt (mvo)]

I just noticed the open task for ubuntu-system-settings about doing a addtional hashsum check for the download. Fwiw, click is already doing a gpg verification before the install so corrupted/MITMed clicks will not get installed there. Having the hash check may still be a good idea for e.g. better error reporting.

[Launchpad Janitor (janitor)]

This bug was fixed in the package ubuntu-system-settings - 0.3+15.04.20150123-0ubuntu1

---------------
ubuntu-system-settings (0.3+15.04.20150123-0ubuntu1) vivid; urgency=low

  [ Manuel de la Peña ]
  * Add support for checksum validation. (LP: #1330770)

  [ Diego Sarmentero ]
  * Add support for checksum validation. (LP: #1330770)
 -- Ubuntu daily release <email address hidden> Fri, 23 Jan 2015 16:53:49 +0000

[Ken VanDine (ken-vandine)]

The fix that landed in trunk isn't quite complete, it does verify the hash properly but doesn't handle the error signal. I'm suspecting it isn't getting the error signal from ubuntu-download-manager.

[Ken VanDine (ken-vandine)]

I added some debug output to download_tracker.cpp, registerError is never getting called, which is the function connected to Download::error. I don't think ubuntu-download-manager is emitting the error when the hash check fails.

[Alejandro J. Cura (alecu)]

Weird, I remember getting errors from download manager when testing the click scope with packages in staging with broken hashes.
Perhaps something changed in download manager since we landed this in the scope (mid august)?

Btw, is there any package in the staging store with broken hash? We can try installing it with the click scope.

[Ken VanDine (ken-vandine)]

I'm using a python script to run a fake server, you can see the instructions in our test plan under "CHECK HASH"

https://wiki.ubuntu.com/Process/Merges/TestPlan/ubuntu-system-settings

[Pat McGowan (pat-mcgowan)]

this seems stalled