Ghost Leak — Pre-Auth Buffer Over-read via TTL=0 + IP Total Length in ArubaOS 8.13.2.0

Submission ID: c5eda0ae — HPE Networking Product Public Program (Bugcrowd)
Status: Closed as “Not Applicable — only zeroed bytes / no confirmed sensitive memory disclosure”
GitHub: github.com/JM00NJ/HPE-Aruba-AOS8-Vulnerabilities

Background

Three weaknesses in ArubaOS 8.13.2.0’s ICMP Echo handler compound into the Ghost Leak attack chain: IP Total Length over-read (CWE-126), TTL=0 acceptance (CWE-1284), and absent checksum validation (CWE-354).

The vulnerability class is EtherLeak — the same mechanism as CVE-2003-0001 and CVE-2021-3031 (Palo Alto PAN-OS), both accepted by their respective vendors without requiring demonstration of sensitive data on physical hardware. Submitted May 15, 2026. Closed citing “only zeroed bytes.”

Target

The Ghost Leak Chain

Component 1 — IP Total Length Over-read (CWE-126)

icmp_payload = IP_Total_Length - 20(IP hdr) - 8(ICMP hdr)

When IP_Total_Length exceeds actual frame data, the handler reads into the Ethernet padding area. On physical hardware: stale DMA ring buffer data.

Threshold table (14 probe values):

Max accepted IP_Total_Length = 46 = Ethernet min frame (60B) minus Ethernet header (14B). The controller reads exactly to the frame boundary — including padding.

Component 2 — TTL=0 Acceptance (CWE-1284)

RFC 791 §3.2: “If this field contains the value zero, then the datagram must be destroyed.”

The controller processes TTL=0 packets and replies with TTL=64. This makes the attack completely invisible:

• Routers don’t forward TTL=0 → no routed trace
• IDS/IPS don’t alert on TTL=0 → should never exist on wire
• Firewalls typically discard TTL=0 → no log entries

Component 3 — No Checksum Validation (CWE-354)

Packets with checksums 0x0000, 0xFFFF, 0x1337 all received replies.

Proof of Concept

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

from scapy.all import *

pkt = IP(dst="192.168.56.50", len=46, ttl=0) / ICMP(type=8, code=0, id=0xDEAD)
ans, _ = sr(pkt, timeout=2, verbose=0)

if ans:
    payload = bytes(ans[0][1][ICMP].payload)
    print(f"Leaked ({len(payload)}B): {payload.hex()}")
    # Virtual NIC:  000000000000000000000000000000000000
    # Physical NIC: stale DMA buffer contents

Verify with tshark:

1
2
3

tshark -r ghost-leak.pcapng \
  -Y "icmp.type == 0 && icmp.ident == 0xdead" \
  -T fields -e ip.len -e icmp.seq -e data.data

Evidence: 27/27 Replies Confirmed

ghost-leak.pcapng:

• 4,999 background packets (control group)
• 27 Ghost Leak packets (TTL=0, len=46, id=0xDEAD)
• 27 replies — 100% response rate

Reply structure:

IP:   TotalLen=46  TTL=64  Src=192.168.56.50
ICMP: Type=0  ID=0xDEAD
Payload: 000000000000000000000000000000000000  (18 bytes)

ip.len=46 in reply confirms inflated length was echoed back.

Why Zeroed Bytes Do Not Negate the Vulnerability

VirtualBox virtual NICs initialize frame padding to zero. This is a documented hypervisor characteristic — not evidence that the over-read is absent.

On physical AOS-8 hardware with a real NIC DMA buffer, the 18-byte region contains previous frame remnants: MAC addresses, IP/port data, management traffic fragments.

CVE precedents accepted on mechanism alone:

• CVE-2003-0001 — EtherLeak via ICMP on multiple NIC drivers. cve.org/CVERecord?id=CVE-2003-0001
• CVE-2021-3031 — Palo Alto PAN-OS: “Packets in the Ethernet frame padding are observable.” Accepted for PA-200 through PA-7000. security.paloaltonetworks.com/CVE-2021-3031

Neither CVE required sensitive data demonstration on specific physical hardware. Both were accepted on the mechanism.

Real-World Impact

At 100 req/s: 18B × 100 = 1,800 B/s = 108 KB/min from NIC buffer.

Combined with TTL=0 invisibility: continuous extraction from management VLAN with zero IDS alerts, zero firewall logs, zero router traces.

Observed Controller Instability

During extended testing, the controller crashed:

[ 533.404270] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* 
[PLANE:34:plane-0] flip_done timed out

Post-reboot log: Reboot Cause: Power Cycle (Intent:cause: 86:50). Simultaneous DRM + network failure suggests kernel-level issue. show log kernel returns “Invalid input” — ArubaOS CLI does not expose kernel logs.

Timeline

Disclosure Note

The program has classified this as a non-vulnerability. No fix issued. This writeup is published for independent community evaluation.

Vesqer / JM00NJ — netacoding.com