Open Stack

OpenStack Security Note: 0074

Nova metadata service should not be used for sensitive information

---

### Summary ###
A recent security report has highlighted how users may be using the
metadata service to store security sensitive information.

The Nova metadata service should not be considered a secure repository
of confidential information required by compute instances.

### Affected Services / Software ###
Nova, All Versions

### Discussion ###
A recent vulnerability report for Nova stated that the metadata service
will obey the `X-Forwarded-For` HTTP header. This header is often
supplied by proxies so that the end service can identify which IP the
request originated from.

The Nova metadata service typically uses the source IP address of the
incoming request to respond with the appropriate data for the compute
instance making the request. This is a sort of weak authentication,
designed to ensure that metadata for one tenant isn't accidentally
provided to another.

If the request contains a `X-Forwarded-For` HTTP header then the
metadata service will use that for the source authentication rather than
the actual TCP/IP source.

An attacker with access to a compute instance in the cloud could send a
request to the metadata service and include the `X-Forwarded-For` header
in order to effectively spoof their source and cause the metadata
service to provide information that should not have been provided to
that instance.

Consider the following:
Alice creates a compute instance. She places the root password for that
instance in the metadata service. The instance is assigned a 10.1.2.2
IP address. Alice believes that the root password for her instance is
safe within the metadata service.

Alice retrieves metadata by running a command similar to:
`curl http://169.254.169.254/latest/meta-data
<http://169.254.169.254/latest/meta-data>`
this will retrieve any metadata stored for Alice's compute instance,
which has an IP address of 10.1.2.2

Bob has a compute instance with IP address 10.1.9.9 however Bob wants
access to the metadata for Alice's compute instance. If Bob runs a
similar command to Alice, but includes a customer header as below, he
will get access to all of Alice's metadata, including the root password
she chose to store there:
`curl -H "X-Forwarded-For:
10.1.2.2" http://169.254.169.254/latest/meta-data
<http://169.254.169.254/latest/meta-data>`

The Nova metadata service is a useful utility within OpenStack but
clearly not intended as a strongly authenticated system for storing
sensitive data such as private keys or passwords.

### Recommended Actions ###
The metadata service should not be used to store sensitive information.

The IP forwarding issue is not a defect of itself, it exists to allow
the metadata service to provide IP addresses for instances that are
behind a proxy as may be the case in more complex deployments.

Cloud users who have a requirement to store sensitive information that
compute instances require for operation should instead look to the
Config drive to provide this service. It's operation is much more
tightly bound to individual compute instances.

Where use of config drive is not an option, operators should consider
other mitigations such as placing a proxy in front of the metadata service
which can filter out these sorts of malicious activities.

### Contacts / References ###
Author: Robert Clark, IBM
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0074
Original LaunchPad Bug : https://bugs.launchpad.net/nova/+bug/1563954
<https://bugs.launchpad.net/nova/+bug/1563954>
Mailing List : [Security] tag on openstack-dev at lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
<https://launchpad.net/%7Eopenstack-ossg>
Config Drive
: http://docs.openstack.org/user-guide/cli-config-drive.html
<http://docs.openstack.org/user-guide/cli-config-drive.html>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161219/1280ea14/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x3C202614.asc
Type: application/pgp-keys
Size: 1698 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161219/1280ea14/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161219/1280ea14/attachment.pgp>