Cloudanix VulnDB

CVE-2011-4600

Medium · 5.9

CVSS

5.9

EPSS

1.8%

Published

Apr 14, 2016

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

Restarting a network service can accidentally remove security barriers, letting outsiders reach systems they should not be able to contact.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Moderate
Impact
Privilege Gain
Component
Library
Class
Authorization Bypass
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The networkReloadIptablesRules function in network/bridge_driver.c fails to properly reapply firewall rules on bridge networks after libvirtd restart, allowing DNS or DHCP queries to bypass intended access restrictions.

Why it matters to the business

Organizations using the affected packages face potential unauthorized network access that could enable lateral movement or exposure of internal resources, with urgency driven by the long period since disclosure and downstream package dependencies.

How an attack unfolds

An attacker identifies an environment running an affected package, waits for or induces a libvirtd restart that drops bridge firewall rules, then issues DNS or DHCP queries that succeed in bypassing the intended restrictions.

How to fix it

Upgrade ingress-nginx-controller (Chainguard) to 1.10.1-r3 or later, ingress-nginx-controller (Wolfi) to 1.10.1-r3 or later, ingress-nginx-controller-compat (Chainguard) to 1.10.1-r3 or later, ingress-nginx-controller-compat (Wolfi) to 1.10.1-r3 or later, kube-webhook-certgen (Chainguard) to 1.10.1-r3 or later, and kube-webhook-certgen (Wolfi) to 1.10.1-r3 or later. Restart services after upgrade and verify rule application.

How to confirm the fix worked

Check installed package versions against the fixed releases, review bridge network firewall state immediately after service restarts, and confirm DNS/DHCP queries are properly filtered by iptables rules.

Typical attack path

  1. Scan for systems exposing bridge networks managed by affected packages
  2. Trigger or observe a libvirtd restart event
  3. Send crafted DNS or DHCP queries to test and exploit the missing rules
  4. Establish unauthorized network connectivity for further actions

How to detect it

Review network and service logs for libvirtd restarts followed by successful DNS or DHCP queries that previously would have been blocked; examine bridge interface traffic patterns for anomalies.

What your security team should do

  • Apply the listed package upgrades immediately across all environments
  • Add monitoring for libvirtd restarts correlated with unexpected network traffic
  • Implement compensating network controls until patches are deployed
  • Audit downstream dependents for additional exposure

The record

The networkReloadIptablesRules function in network/bridge_driver.c in libvirt before 0.9.9 does not properly handle firewall rules on bridge networks when libvirtd is restarted, which might allow remote attackers to bypass intended access restrictions via a (1) DNS or (2) DHCP query.

Affected packages

Ecosystem Package Introduced Fixed
Debian:10 libvirt 0 0.9.9-1
Debian:11 libvirt 0 0.9.9-1
Debian:12 libvirt 0 0.9.9-1
Debian:13 libvirt 0 0.9.9-1
Red Hat:rhel_eus:6.2::server libvirt 0 0:0.9.4-23.el6_2.4
Red Hat:rhel_eus:6.2::server libvirt-client 0 0:0.9.4-23.el6_2.4
Red Hat:rhel_eus:6.2::server libvirt-debuginfo 0 0:0.9.4-23.el6_2.4
Red Hat:rhel_eus:6.2::server libvirt-devel 0 0:0.9.4-23.el6_2.4
Red Hat:rhel_eus:6.2::server libvirt-lock-sanlock 0 0:0.9.4-23.el6_2.4
Red Hat:rhel_eus:6.2::server libvirt-python 0 0:0.9.4-23.el6_2.4
Ubuntu:14.04:LTS libvirt 0 1.2.2-0ubuntu13.1.14
Ubuntu:14.04:LTS libvirt 0 1.2.2-0ubuntu13.1.16
openSUSE:Tumbleweed libvirt 0 2.5.0-1.1

Related vulnerabilities