Interaction error in OpenStack Nova and Neutron before Havana 2013.2.1 and icehouse-1 does not validate the instance ID of the tenant making a request, which allows remote tenants to obtain sensitive metadata by spoofing the device ID that is bound to a port, which is not properly handled by (1) api/metadata/handler.py in Nova and (2) the neutron-metadata-agent (agent/metadata/agent.py) in Neutron.

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - Interaction error in OpenStack Nova and Neutron before Havana 2013.2.1 and icehouse-1 does not validate
    the instance ID of the tenant making a request, which allows remote tenants to obtain sensitive metadata
    by spoofing the device ID that is bound to a port, which is not properly handled by (1)
    api/metadata/handler.py in Nova and (2) the neutron-metadata-agent (agent/metadata/agent.py) in Neutron.
    (CVE-2013-6419)

The remote Redhat Enterprise Linux 6 host has packages installed that are affected by a vulnerability as referenced in the RHSA-2014:0091 advisory.

    The openstack-neutron packages provide Openstack Networking (neutron), the     virtual network service.

    It was discovered that the metadata agent in OpenStack Networking was     missing an authorization check on the device ID that is bound to a specific     port. A remote tenant could guess the instance ID bound to a port and     retrieve metadata of another tenant, resulting in information disclosure.
    Note that only OpenStack Networking setups running neutron-metadata-agent     were affected. (CVE-2013-6419)

    Red Hat would like to thank Jeremy Stanley of the OpenStack Project for     reporting this issue. Upstream acknowledges Aaron Rosen of VMware as the     original reporter.

    The openstack-neutron packages have been upgraded to upstream version     2013.2.1, which provides a number of bug fixes and enhancements over the     previous version. The most notable fixes and enhancements are:

    - Support for multiple workers in the Neutron API. This can be achieved by       setting the 'workers=' parameter in the neutron.conf file.

    - The downtime and report interval default settings are tuned for       neutron agents.

    - The floating IP address stability has been enhanced.

    - A heartbeat-related deadlock problem in neutron-server has been fixed.

    (BZ#1045419)

    This update also fixes the following bugs:

    * An incorrect warning was displayed when running neutron-dhcp-agent with     Red Hat Enterprise Linux's version of dnsmasq. This meant that users were     incorrectly warned that Red Hat Enterprise Linux's dnsmasq version will not     work with neutron-dhcp-agent. This warning has been removed, and will no     longer be logged to the neutron-dhcp-agent log file. (BZ#1040196)

    * A bug in the QPID topic consumer re-connection logic (under the v2     topology) caused qpidd to use a malformed subscriber address after     restarting, resulting in RPC requests sent to a topic with multiple servers     ending up being incorrectly multicast to all servers. This update removes     the special-case reconnect logic that handles UUID addresses, which in turn     avoids the incorrect establishment of multiple subscription to the same     fanout address. The QPID broker now simply automatically generates unique     queue names when clients reconnect. (BZ#1045067)

    * Thread-consuming QPID messages were killed silently by unhandled errors,     thus resulting in isolating the component from the rest of the system.
    With this update, consuming threads are made more resilient to errors by     ensuring they do not die on an unhandled error. The error is now logged,     and the consuming thread is retried. (BZ#1054249)

    In addition, this update adds the following enhancement:

    * Previously, instances connected to tenant networks gained outside     connectivity by going through an SNAT by the L3 agent hosting that     network's virtual router. With this release, the ability to disable     SNAT/PAT on virtual servers is added ensuring that an instance in a tenant     network subnet will retain its IP address as it passes through external     networks. For example, if 10.0.0.1 is an instance in the 10.0.0.0/8 tenant     network, R1, a virtual router that connects the 10.0.0.0/8 subnet to the     20.0.0.0/8 public provider networks, then you can use the 'neutron     router-gateway-set --disable-snat R1 public' command and any traffic from     10.0.0.1, which is forwarded out to the provider network, will retain its     actual source IP address of 10.0.0.1. This can be a flexible and useful     method to connect instances directly to a provider network, while retaining     it in a tenant network. (BZ#1046070)

    All openstack-neutron users are advised to upgrade to these updated     packages, which correct these issues and add these enhancements.

Tenable has extracted the preceding description block directly from the Red Hat Enterprise Linux security advisory.

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

ID	Name	Product	Family	Severity
436934	SCA: security update for nova (GHSA-22w9-j288-8p9w)	Tenable Cloud Security	SCA Checks	high
436934	SCA: security update for nova (GHSA-22w9-j288-8p9w)	Tenable Self-Hosted Container Security	SCA Checks	high
210217	RHEL 6 : openstack-neutron (RHSA-2014:0091)	Nessus	Red Hat Local Security Checks	medium

Detections

Analytics

CVE-2013-6419

high

Tenable Plugins

high

high

medium