----- Original Message ----- > From: "Luke Hinds" <lhi...@redhat.com> > To: openstack@lists.openstack.org, openstack-...@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-...@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@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > -- Steve Gordon, Principal Product Manager, Red Hat OpenStack Platform _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack