Difference between revisions of "OSSN/OSSN-0074"
(Created page with "--Work in Progress--") |
(adding ossn-0074) |
||
| Line 1: | Line 1: | ||
| − | -- | + | __NOTOC__ |
| + | |||
| + | ==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` | ||
| + | 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` | ||
| + | |||
| + | 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 | ||
| + | |||
| + | Mailing List : [Security] tag on openstack-dev@lists.openstack.org | ||
| + | |||
| + | OpenStack Security Group : https://launchpad.net/~openstack-ossg | ||
| + | |||
| + | Config Drive : http://docs.openstack.org/user-guide/cli-config-drive.html | ||
Latest revision as of 09:24, 19 December 2016
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` 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`
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
Mailing List : [Security] tag on openstack-dev@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
Config Drive : http://docs.openstack.org/user-guide/cli-config-drive.html
