maas-import-pxe-files doesn't cryptographically verify what it downloads

Bug #1039513 reported by Robie Basak
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MAAS
Fix Released
Critical
Julian Edwards
1.2
Fix Released
Critical
Julian Edwards
1.3
Fix Released
Critical
Julian Edwards

Bug Description

Currently, maas-import-pxe-files uses HTTP to download its files, including pxelinux.0 and netboot kernel image and initrd. In theory, somebody could intercept this and inject a malicious payload.

maas-import-ephemerals avoids this by using HTTPS, but:
  1) This prevents (easy) caching
  2) archive.ubuntu.com doesn't appear to support HTTPS
  3) The files we need are indirectly signed, so if we just try to verify what is there we'll end up with the same race condition that apt faces in bug 972077

Revision history for this message
Scott Moser (smoser) wrote :

fwiw, this is a regression over the use of 'cobbler-ubuntu-import', which does do gpg checking against /usr/share/keyrings/ubuntu-archive-keyring.gpg [1]. That was added under bug 974460.

Outside of the race condition, which I'm willing to ignore for the time being, we can just use the same solution there.

Note also that a "InRelease" (signed content in same file as payload) does not fix this entirely either, as there is still the race between downloading the ISO and the the signed file.

--
[1] http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/quantal/cobbler/quantal/view/head:/debian/cobbler-ubuntu-import#L86

summary: - maas-import-pxe-files should cryptographically verify what it downloads
+ maas-import-pxe-files doesn't cryptographically verify what it downloads
Changed in maas:
status: New → Triaged
importance: Undecided → High
Revision history for this message
Scott Moser (smoser) wrote :

this bug has now been copied over to maas-import-squashfs

tags: added: m-i-p-f tech-debt
Revision history for this message
Scott Moser (smoser) wrote :

The end goal is for downloading to use simplestreams data, and for us to have simplestreams data describing each of
 1. installer kernel/initramfs
 2. maas ephemeral images
 3. fast path images (if different than 2)

So we hope to use that data, and then also use the sstream-sync client (or an improvement upon it) to pull this data down. That client will then correctly check signatures and sizes and support mirrors.

Revision history for this message
Julian Edwards (julian-edwards) wrote :

I am doing a quick fix for now.

Eventually, we'll replace all the shell with unit-tested Python and hook it into simplestreams.

Changed in maas:
assignee: nobody → Julian Edwards (julian-edwards)
status: Triaged → In Progress
Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

This is CVE-2013-1058

Revision history for this message
Seth Arnold (seth-arnold) wrote :

Can you recommend the correct Depends: additions for this change? I'm guessing it'll need at least "gpgv, ubuntu-keyring" added to maas-cluster-controller. Is this sufficient? Would something else be better?

On a second note, I believe I can test these changes specifically without too much hassle, but full end-to-end smoke testing of MAAS may take me a while to configure. Is there another way to test MAAS packages you can recommend?

Thanks

Revision history for this message
Seth Arnold (seth-arnold) wrote :

Julian, I've of course realized that 'gpgv' is the wrong package to add to the dependencies for this patch -- but I have to ask if gpgv would give better results / more predictable results.

Granted, MAAS is something special and it is unlikely that the MAAS user would have a GnuPG configuration but gpgv was introduced for a reason, and I'm curious if this is the perfect use for it.

What do you think? Have you had a chance to test this code with 'active' users who might have modified their GnuPG configuration?

Thanks

Revision history for this message
Seth Arnold (seth-arnold) wrote :

Julian, I've talked a bit more about this with Marc -- he's fine with 'gpg' rather than 'gpgv' because 'gpg' is in the default packages. And, as a result, there's no need to modify the dependencies either. (It might not be news to you, but it was news to me. :)

So, I think it's fair to ignore my previous few comments, though if there is an easier way to test MAAS end-to-end than described https://wiki.ubuntu.com/SecurityTeam/TestingMAAS I'm still curious. :)

Thanks.

Revision history for this message
Julian Edwards (julian-edwards) wrote :

We normally use the Lexington QA lab to test things, or a few of us have a local set up with some hardware as well. I have tested the patch, of course! :) But I can verify new packages as well if you want, let me know when/where they are.

The new commands depend on gnupg and coreutils packages.

Cheers.

information type: Private Security → Public
Changed in maas:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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