CVE-2023-28842: Mobyproject Moby Encryption Vulnerability

CVE-2023-28842 Overview

CVE-2023-28842 is a network protocol vulnerability affecting the Moby open source container framework, which is the foundation for Docker, Mirantis Container Runtime, and various downstream container products. The vulnerability resides in the encrypted overlay network driver used in Docker Swarm Mode, allowing attackers to inject arbitrary cleartext VXLAN datagrams into encrypted overlay networks.

The overlay network driver is a core component of Swarm Mode, providing isolated virtual LANs for container communication across cluster nodes using VXLAN encapsulation. When encryption is enabled, IPsec Encapsulating Security Payload (ESP) protocol in Transport mode is used to provide source authentication, data integrity, and confidentiality. However, a flaw in the iptables rule configuration allows encrypted overlay networks to silently accept unencrypted VXLAN packets tagged with a valid VNI, bypassing the intended encryption guarantees.

Critical Impact
Attackers with network access can inject arbitrary Ethernet frames into encrypted overlay networks by encapsulating them in cleartext VXLAN datagrams, completely undermining the confidentiality and integrity guarantees of encrypted overlay networks.

Affected Products

Moby versions prior to 23.0.3
Moby versions prior to 20.10.24
Mirantis Container Runtime versions prior to 20.10.16

Discovery Timeline

April 4, 2023 - CVE CVE-2023-28842 published to NVD
November 21, 2024 - Last updated in NVD database

Technical Details for CVE-2023-28842

Vulnerability Analysis

The vulnerability stems from a timing-based configuration flaw in how the Moby daemon dynamically configures encrypted overlay networks. The overlay driver lazily defines kernel configuration for VXLAN networks on each node as containers are attached and detached. Routes and encryption parameters are only established for destination nodes actively participating in the network.

The critical flaw lies in the iptables rules that enforce IPsec encryption: these rules are not created until a peer node is available with which to communicate. This creates a window where the encrypted overlay network lacks the firewall protections needed to reject unencrypted traffic. The rules rely on the u32 iptables extension (provided by the xt_u32 kernel module) to filter VXLAN packets based on their VNI field, but the delayed rule creation undermines this protection mechanism.

Root Cause

The root cause is the lazy initialization of iptables rules that prevent unencrypted packets from being accepted on encrypted overlay networks. The iptables rules that enforce IPsec encapsulation are not created proactively when an encrypted overlay network is established. Instead, they are only defined when a peer becomes available for communication. This design decision, combined with the dynamic nature of Swarm Mode container orchestration, creates scenarios where the encrypted overlay network silently accepts cleartext VXLAN datagrams tagged with the correct VNI.

Attack Vector

An attacker positioned on the network path between Docker Swarm nodes can exploit this vulnerability by crafting and injecting VXLAN-encapsulated Ethernet frames. The attack requires:

Network access to intercept or inject traffic between Swarm cluster nodes
Knowledge of the target encrypted overlay network's VXLAN Network ID (VNI)
The ability to send UDP datagrams to port 4789 (standard VXLAN port)

The attacker constructs cleartext VXLAN datagrams containing malicious Ethernet frames, tags them with the target network's VNI, and transmits them to the target node. Due to the missing iptables rules during the vulnerable window, the node accepts these unencrypted packets as legitimate overlay network traffic, allowing the attacker to inject arbitrary data into what should be an encrypted communication channel.

This attack is particularly dangerous in multi-cloud or hybrid deployments where VXLAN traffic must traverse untrusted networks between nodes.

Detection Methods for CVE-2023-28842

Indicators of Compromise

Unencrypted VXLAN traffic (UDP port 4789) between Docker Swarm nodes that should be using encrypted overlay networks
Unexpected network traffic or communications within overlay networks from unknown sources
Missing or incomplete iptables rules for IPsec enforcement on overlay network interfaces
Anomalous Ethernet frames appearing within encrypted overlay networks without corresponding IPsec ESP headers

Detection Strategies

Monitor for VXLAN packets (UDP 4789) that lack IPsec ESP encapsulation between nodes configured for encrypted overlay networks
Implement network intrusion detection rules to alert on cleartext VXLAN traffic in environments using encrypted overlays
Audit iptables rules on Swarm nodes to verify IPsec enforcement rules are properly configured for all encrypted overlay networks
Deploy packet capture and analysis on network segments between Swarm nodes to identify unencrypted overlay traffic

Monitoring Recommendations

Enable network flow logging to track VXLAN traffic patterns between cluster nodes
Implement alerting for UDP port 4789 traffic that bypasses IPsec validation
Monitor Docker daemon logs for overlay network initialization events and correlate with iptables rule creation
Deploy host-based monitoring on Swarm nodes to track iptables rule state changes related to overlay networks

How to Mitigate CVE-2023-28842

Immediate Actions Required

Update Moby/Docker to version 23.0.3 or later, or version 20.10.24 or later
For Mirantis Container Runtime users, upgrade to version 20.10.16 or later
Block UDP port 4789 from traffic that has not been validated by IPsec if encrypted overlay networks are in exclusive use
Deploy a global 'pause' container for each encrypted overlay network on every node in multi-node clusters to ensure iptables rules are created

Patch Information

Security patches addressing this vulnerability are available in the following releases:

Moby 23.0.3 - Full fix for encrypted overlay network packet injection
Moby 20.10.24 - Backported fix for the 20.10 LTS branch
Mirantis Container Runtime 20.10.16 - Equivalent fix for Mirantis-branded releases

Organizations should review the GitHub Security Advisory GHSA-6wrf-mxfj-pf5p for detailed patch information and the related advisory GHSA-vwm3-crmr-xfxw for deeper exploration of the implications.

Workarounds

For single-node clusters, avoid using overlay networks entirely and use bridge networks instead, which provide equivalent connectivity without multi-node features
Disable the Swarm ingress feature by publishing ports in host mode instead of ingress mode and using an external load balancer, then remove the ingress network
If encrypted overlay networks are exclusively used, implement firewall rules to block UDP port 4789 from any traffic not validated by IPsec
Deploy a global service running a minimal 'pause' container attached to each encrypted overlay network across all Swarm nodes to force iptables rule creation

bash

# Example: Deploy global pause container to force iptables rule creation
docker service create --name overlay-fix \
  --mode global \
  --network encrypted-overlay-network \
  --restart-condition none \
  gcr.io/google_containers/pause:3.2

# Alternative: Block non-IPsec VXLAN traffic at the firewall level
iptables -I INPUT -p udp --dport 4789 \
  -m policy --dir in --pol none \
  -j DROP