launchpad-reviewers team mailing list archive

[Launchpad Bug Tracker <1034116@xxxxxxxxxxxxxxxxxx>]

** Branch linked: lp:~ubuntu-on-ec2/vmbuilder/automated-ec2-builds

-- 
You received this bug notification because you are a member of MAAS
Maintainers, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1034116

Title:
  transition from allocated to commissioning could be poisoned

Status in cloud-initramfs-tools:
  Fix Released
Status in MAAS:
  New
Status in “cloud-initramfs-tools” package in Ubuntu:
  Fix Released
Status in “maas” package in Ubuntu:
  New

Bug description:
  overlayroot and cloud-initramfs-rescuevol have code in them that run in the
  initramfs and make decisions based on block devices that are present.
   * overlayroot will search for a filesystem on a block device with
     LABEL=OROOTCFG. if found, and a file /overlayroot.conf exists there, it
     will shell-source this file.
     overlayroot is new in quantal.
   * cloud-initramfs-rescuevol will search for a filesystem labeled 'RESCUE_VOL'
     if such a filesystem exists, it basically overrides 'root=' parameter
     and boots off that instead.

  Both of these features were added to enable users in a cloud environment
  to affect early boot of an instance.  On EC2, and potentially other clouds,
  the user can attach a block device to a new or existing instance with arbitrary
  data.  Then on start (or reboot) that block device could affect the boot,
  allowing the user to configure overlayroot or rescue their system.

  Maas's "ephemeral" is created from cloud images. As a result, these code paths
  are live.

  A potential exploit then is
   * user reserves or checks out a new node, does some work on it and the returns
     it.  But before returning it, he sets the LABEL on a filesystem to one
     of the values listed above.
   * if the node is then installed, there is not a problem that i'm aware of.
   * if the node goes into commissioning, though, the node will boot off of
     iscsi with a initramfs that will look at local devices and let the attacker
     gain control in the commissioning environment.

  The fix for overlayroot seems to me to be adding an option that would be read
  by overlayroot and disable the behavior.  Then, the commissioning and enlistment
  environments would set this.

  The same sort of fix could be applied to rescuevol, but we might consider
  removing it from the images as I've not ever publicized this path, and the
  overlayroot path is actually probably easier to utilize.

  I'm not aware if there is any code in the installer which could be affected by
  this same attack.  I know that I have asked cjwatson for the ability to put a
  preseed file on external media before, but he resisted.

  TODO:
   * cloud-initramfs-tools:
     * overlayroot: disable the search for LABEL=OROOTCFG by default on installation
     * overlayroot: add configuration option of this and document in /etc/overlayroot.conf
     * overlayroot: allow enabling on kernel command line and in rootdir/etc/overlayroot.conf
     * rescuevol: allow disabling via kernel cmdline and SRU 'rescuevol=disabled'
   * cloud-images
     * [DONE] remove rescuevol package from seed
     * enable LABEL=OROOTCFG in overlayroot package during image build
   * maas:
     * modify install preseed to make sure we 'wipefs' on all filesystems
     * [SKIPPED] modify ephemeral and enlistment environment to pass 'rescuevol=disabled'
       we disable the behavior in future images, and quantal images will not have rescuevol.
   * maas-ephemeral-images:
     * disable LABEL=OROOTCFG in ephemeral environment
     * [SKIPPED] remove rescuevol package from precise future builds
       if we disable rescuevol, by the /etc/rescuevol-ignore path, it should be fine.
     * disable resuevol in image by touching /etc/rescuevol-ignore

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-initramfs-tools/+bug/1034116/+subscriptions