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

Bug #1039513 reported by Robie Basak on 2012-08-21
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Julian Edwards
Julian Edwards
Julian Edwards
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) 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

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.


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
Scott Moser (smoser) wrote :

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

tags: added: m-i-p-f tech-debt
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.

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
Marc Deslauriers (mdeslaur) wrote :

This is CVE-2013-1058

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?


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?


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 I'm still curious. :)


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.


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  Edit
Everyone can see this information.

Other bug subscribers