Bug 1410773

Summary:	nova metadata exposure
Product:	Red Hat OpenStack	Reporter:	Nilesh <nchandek>
Component:	openstack-nova	Assignee:	Eoghan Glynn <eglynn>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Prasanth Anbalagan <panbalag>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	9.0 (Mitaka)	CC:	awaugama, berrange, dasmith, eglynn, kchamart, nchandek, rcritten, sbauza, sferdjao, sgordon, srevivo, vromanso
Target Milestone:	---	Flags:	nchandek: automate_bug? nchandek: internal-review?
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-01-23 20:35:34 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Nilesh 2017-01-06 12:41:44 UTC

Description of problem:

The nova metadata service uses the remote address to determine which metadata to retrieve, which will use the X-Forwarded-For header to determine the remote IP.

If this option is set then anyone who can access the metadata port can request metadata for any instance if they know the IP.

The user data is also exposed.

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.

Version-Release number of selected component (if applicable):

Redhat Openstack 10 RHOSP-10

How reproducible:

Steps to Reproduce:
~~~
$ echo 123456 > /tmp/data
$ openstack server create --image CentOS7 --flavor fedora --user-data /tmp/data test
<wait>
$ curl -H 'X-Forwarded-For: 10.0.0.7' http://localhost:8775/latest/user-data/
123456
~~~

Actual results:

The nova metadata should not be exposed to anyone.

Expected results:

The nova metadata should not be exposed to anyone.

Additional info:

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.

Comment 1 Nilesh 2017-01-06 12:43:22 UTC

Upstream bug is already open for this issue. 

https://bugs.launchpad.net/nova/+bug/1563954/

Comment 10 Stephen Gordon 2017-01-23 20:35:34 UTC

I have discussed this with the security folks internal to Red Hat and also on the upstream mailing list [1]. It was discussed in the bug by not explicitly called out in OSSN-0074 but this issue only presents if Nova's use_forwarded_for configuration variable is set to True.

Both Nova and the TripleO tooling we use to deploy it default this variable to False, thus unless the customer explicitly overrides this for their installation and sets use_forwarded_for to True they will be unaffected by this issue.

If they do set this value to True, then they are telling Nova to rely on X-Forwarded-For so that they can put a proxy in front of it. As part of configuring such a proxy they will need to ensure their network is design correctly such that untrusted systems can not connect directly to the service without going through the proxy, and also ensure their proxy correctly rewrites any existing X-Forwarded-For headers it may receive rather than passing them through untouched

As the out of the box configuration we provide is not impacted I am closing this as CLOSED CURRENTRELEASE. They are of course welcome to try the reproducer listed in the OSSN [2] and verify for themselves.

[1] http://lists.openstack.org/pipermail/openstack-dev/2017-January/110500.html
[2] https://wiki.openstack.org/wiki/OSSN/OSSN-0074

Comment 11 Nilesh 2017-02-06 14:17:00 UTC

Thank you Stephen Gordon for speeding this up.