OpenBSD - Remote Kernel PAP Authentication Bypass
sppp_pap_input uses attacker-controlled length fields directly as bcmp comparison length, allowing zero-length authentication bypass.
- Vendor
- OpenBSD
- Product
- OpenBSD
- Affected
- 7.6 confirmed; likely all prior versions
- Fixed in
- 2026-06-14
Executive Summary
The sppp_pap_input function in sys/net/if_spppsubr.c uses the attacker-controlled name_len and passwd_len fields from the incoming PAP frame directly as the comparison length for bcmp against configured credentials. Sending both as zero causes bcmp to return 0 unconditionally, bypassing authentication entirely.
Details
The credential check compares the peer-supplied name and password against stored values using bcmp(..., name_len) and bcmp(..., passwd_len). When bcmp is called with length 0, it always returns 0 regardless of the buffer contents. The existing > AUTHMAXLEN guard allows zero through, so a PAP Auth-Request with name_len=0 and passwd_len=0 passes validation and triggers a PAP_ACK.
A secondary issue arises from the same root cause: supplying a name_len larger than the allocated credential string causes bcmp to read past the heap object, producing a kernel heap over-read.
Reachability
Both issues are reachable via the PPPoE data path (pppoe_data_input → sppp_input → sppp_pap_input) on systems configured as a PAP authenticator. No credentials need to be known by the attacker.
Impact
An attacker on the same network segment can authenticate to a PPPoE interface without knowing any configured credentials, establishing a full network-layer link. This enables traffic interception when OpenBSD acts as a PPPoE client with mutual authentication.
Timeline
- 2026-06-12 — Reported to OpenBSD with proof of concept
- 2026-06-14 — Fix committed openbsd/src@076e2b1