yahoo-eng-team team mailing list archive

[Chad Smith <1865947@xxxxxxxxxxxxxxxxxx>]

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

Private security bug reported:

Cloud-init persists world-readable instance metadata in /run/cloud-init
/instance-data.json and a read-only root /run/cloud-init/instance-data-
sensitive.json.

Any sensitive metadata provided by a cloud platform's metadata services
should be redacted from instance-data.json by cloud-init if that
DataSource class defines a list of sensitive metadata key names as a a
class attribute "sensitive_metadata_keys".

Cloud-init matches redacts the correct sensitive keys if discovered when crawling metadata, but it then writes the unredacted information to the world readable /run/cloud-init/instance-data.json 
instead of the root read-only /run/cloud-init/instance-data-sensitive.json.

See the related code at:
https://github.com/canonical/cloud-init/blob/master/cloudinit/sources/__init__.py#L318-L323


This can affect any Datasource if either of the following apply:
 1. It is not DataSourceEc2 and the platform metadata contains a sensitive 'security-credentials' key
 2. It is a private subclassed DataSource that is not present in cloud-init upstream but has set the class attribute sensitive_metadata_keys to be something other that sensitive_metadata_keys = ['security_credentials']


The end result is the sensitive keys they thought they were redacting, end up being published to the world-readable /run/cloud/instance-data.json.


In practice, the only cloud we are aware of that provides a 'security-credentials' key in metadata is Ec2 on VMs that are created with an IAM profile.  This security exposure on Ec2 only is also negated because the utility that crawls ec2 metadata service also happens to skip 'security-credntials' when crawling metadata so cloud-init doesn't see that key anyway.

See this code:
https://github.com/canonical/cloud-init/blob/master/cloudinit/ec2_utils.py#L87-L89

** Affects: cloud-init
     Importance: Undecided
         Status: New

** Information type changed from Public to Private Security

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1865947

Title:
  instance-data.json could contain security sensitive content

Status in cloud-init:
  New

Bug description:
  Cloud-init persists world-readable instance metadata in /run/cloud-
  init/instance-data.json and a read-only root /run/cloud-init/instance-
  data-sensitive.json.

  Any sensitive metadata provided by a cloud platform's metadata
  services should be redacted from instance-data.json by cloud-init if
  that DataSource class defines a list of sensitive metadata key names
  as a a class attribute "sensitive_metadata_keys".

  Cloud-init matches redacts the correct sensitive keys if discovered when crawling metadata, but it then writes the unredacted information to the world readable /run/cloud-init/instance-data.json 
  instead of the root read-only /run/cloud-init/instance-data-sensitive.json.

  See the related code at:
  https://github.com/canonical/cloud-init/blob/master/cloudinit/sources/__init__.py#L318-L323

  
  This can affect any Datasource if either of the following apply:
   1. It is not DataSourceEc2 and the platform metadata contains a sensitive 'security-credentials' key
   2. It is a private subclassed DataSource that is not present in cloud-init upstream but has set the class attribute sensitive_metadata_keys to be something other that sensitive_metadata_keys = ['security_credentials']

  
  The end result is the sensitive keys they thought they were redacting, end up being published to the world-readable /run/cloud/instance-data.json.

  
  In practice, the only cloud we are aware of that provides a 'security-credentials' key in metadata is Ec2 on VMs that are created with an IAM profile.  This security exposure on Ec2 only is also negated because the utility that crawls ec2 metadata service also happens to skip 'security-credntials' when crawling metadata so cloud-init doesn't see that key anyway.

  See this code:
  https://github.com/canonical/cloud-init/blob/master/cloudinit/ec2_utils.py#L87-L89

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1865947/+subscriptions