Our news feeds are filled with reports of malicious attacks on open source code at the project source, most of which are bad actors leveraging code bases for their own gain. While we're taking this growing issue more seriously than anyone else, we're also not taking our eye off the thousands of other types of vulnerabilities that are just as important to understand.For instance, sometimes a well meaning code upgrade meant to improve developer experience and migration performance for one component ends up creating a problem with another and in so doing, opens up an opportunity for attack. Such is the case with September’s Nexus Intelligence Insight CVE-2019-15753, a potential DoS, information exposure vulnerability. In this edition, we’ll cover a PyPI component that by mishandling MAC address table aging, creates a vector for compromise. We’ll talk about how that mishandling could be leveraged and what developers using this code can do to mitigate their risk.
Name of Vulnerability: CVE-2019-15753
Type of Vulnerability: DoS, Information Exposure
Component Name: OpenStack `os-vif`
Components Affected: PyPI: os-vif: [1.15.0, 1.15.2), [1.16.0, 1.17.0)
CVSS 3.0 Score: 9.1 CRITICAL
CVSS 3.0 Metrics: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H
The 'os-vif' package is vulnerable to Improper Input Validation leading to Denial of Service (DoS), potential sensitive Information Exposure, and other security issues. The 'add' function in 'impl_pyroute2.py' contains a hardcoded value of '0' for 'IFLA_BR_AGEING_TIME' which disables MAC learning aging indefinitely. An attacker can exploit this vulnerability on certain deployments (which use the linuxbridge backend) to disrupt network performance and potentially intercept packets belonging to other hosts present on the same network.
The unintentional hard coding of the MAC address aging set to 0 for edge case migration issues when code was being deployed created a potential vulnerability for deployments using the linuxbridge backend.
First, a few basics about MAC address learning. Switches use MAC address learning to speed up the time it takes to switch or forward the originating frame to the appropriate device on the network. By “learning” which MAC addresses belong to which interface, the switch can easily get information where it needs to go without unnecessary processing churn.
A more visual representation of how MAC learning works (credit to http://www.practicalnetworking.net/):
MAC address aging is typically set to a default of 300 seconds. That’s the amount of time the table keeps the information about the devices on the network and on what ports they are present before clearing the cache. Aging time set too high means that the MAC table eventually fills up and frames are broadcast across the network. Too low, as is the case with CVE-2019-1573, and the MAC table never “relearns” which frames belong where, and resorts to broadcasting frames across the network.
In addition to flooding a device with requests and overwhelming the network with broadcasts, someone with the knowledge of this vulnerable vector could potentially intercept frames meant for a specific MAC address on the network and read the frame contents.
Here’s an example of how a typical attack might work:
The device running the vulnerable `os-vif` version in a linuxbridge implementation has its MAC address table “aging” disabled due to a hardcoded setting. During the initial discovery the device’s MAC address table gets populated once. However, because the “aging” for MAC address table entries is set to an unlimited value, the entries never drop the table and as a result relearning does not occur.
Messages (frames) being sent from one host to another on the network may initially go through without any issues, however in case of a major network configuration change, especially involving large networks connected by multiple switches and gateways, the device running the `os-vif` version continues to store a dated MAC address table. This means a slight topology change could lead to the frames being directed to the wrong interfaces (ports) of the devices or switches even though the old host is no longer present there. Over time, this may cause network congestion and affect performance due to multiple frames not reaching their intended destination. In addition, the other devices on the network are forced to listen for and examine frames not intended for them before they are eventually discarded.
Naturally, from a security perspective, one of the obvious implications that follows is, a frame that was meant for a certain host previously present on port 1, for example, continues to be redirected to port 1 even though the actual path to the host might now have changed. The recipient host on port 1 may now have the ability to intercept the incoming frames which were not destined for this device, thereby potentially leading to Information Exposure.
TL;DR: the video version for those who prefer to watch instead of read
We recommend upgrading to a version of this component that is not vulnerable to this specific issue. As of today, the fix for this vulnerability is present in `os-vif` version 1.17.0, as available in PyPI downloads. Users of 1.15.x versions can also upgrade to the recently released 1.15.2 version.
DevOps-native organizations with the ability to continuously deploy software releases have an automation advantage that allows them to stay one step ahead of the hackers. Customers of Sonatype Nexus were notified of CVE-2019-15753 within hours of the project being notified. Their development teams automatically received instructions on how to remediate the risk.
If you're not a Sonatype customer and want to find out if your code is vulnerable, you can use Sonatype's free Nexus Vulnerability Scanner to quickly find out.
Visit the Nexus Intelligence Insights page for a deep dive into other vulnerabilities like this one or subscribe to the blog to automatically receive Nexus Intelligence Insights hot off the press.