Open Stack

----- Original Message -----
> From: "Luke Hinds" <lhinds at redhat.com>
> To: openstack at lists.openstack.org, openstack-dev at lists.openstack.org
> Sent: Monday, December 19, 2016 4:26:24 AM
> Subject: [Openstack] [OSSN-0074] Nova metadata service should not be used for sensitive information
> 
> 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.

Hi Luke,

Does this configuration directive provide any mitigation for this issue?:

"use_forwarded_for = False         (BoolOpt) Treat X-Forwarded-For as the canonical remote address. Only enable this if you have a sanitizing proxy."

Just given its name and stated purpose it seems conspicuous by its absence in this OSSN (that is, even if it provides no mitigation at all I would have expected to see that noted)?

Thanks,

Steve

> 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>
> 
> 
> _______________________________________________
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> 

-- 
Steve Gordon,
Principal Product Manager,
Red Hat OpenStack Platform