OpenBSD PAP authentication bypass through zero-length credential fields

sppp_pap_input in sys/net/if_spppsubr.c in OpenBSD before 076e2b1 allows authentication bypass via certain zero values for lengths.

• The public technical report identifies OpenBSD through 7.6 as affected.
• The normalized record represents the affected range as Git revisions beginning at 0 and less than commit 076e2b1.
• The fix was committed to -current at 076e2b1. The supplied evidence does not identify specific packaged release versions or establish the status of every parallel release branch.

OpenBSD processes PAP in sppp_pap_input within sys/net/if_spppsubr.c. The name_len and passwd_len fields are taken directly from the peer-supplied PAP frame and used as the lengths for bcmp comparisons against the configured username and password. The existing check only rejects values above AUTHMAXLEN, so zero remains valid; bcmp with a length of zero succeeds without comparing data, preventing the authentication-failure branch from being taken and allowing the peer to receive a PAP_ACK without valid credentials.

The vulnerable path is reachable through PPPoE when the target is configured as a PAP authenticator. The same root cause also permits a supplied length larger than the allocation holding a stored credential, causing a kernel heap over-read. Public technical evidence confirms this out-of-bounds read, but does not establish a specific information-disclosure result beyond reading past the object boundary.

The flaw is reachable from the same network segment as the target through the PPPoE path when the interface is configured for PAP authentication. The attacker does not need to know the username or password and no user interaction is required; exploitation requires constructing and completing the relevant PPPoE and PAP negotiation, so it is not merely an arbitrary packet submission. A public proof of concept has been documented that sends zero-length name and password fields, receives a PAP_ACK, and completes IP-layer link negotiation. The supplied evidence does not establish exploitation in the wild.

The flaw lets a peer without valid credentials pass PAP validation and reach an established PPP network-link state. For an OpenBSD PPPoE client, a rogue server in the same broadcast domain may become the endpoint through which traffic is routed, changing the trust boundary of the connection and potentially affecting traffic confidentiality or integrity. For an OpenBSD PAP authenticator, the primary effect is unauthorized peer authentication. The kernel heap over-read is an additional documented consequence, but the supplied evidence does not prove that it directly enables code execution or a specific disclosure outcome.

OpenBSD systems using PPPoE with PAP may accept an unauthorized peer and establish a network link without validating its identity. When OpenBSD operates as a PPPoE client, a rogue server in the same broadcast domain may cause IP traffic to be routed through the attacker's endpoint, creating a risk of traffic exposure or modification within that connection path. When OpenBSD operates as a PAP authenticator, the direct consequence is unauthorized access to the PAP-protected PPP link. The related kernel heap over-read may affect stability or security, but the available evidence does not define its specific data-handling consequence.

1. Update the OpenBSD source or package state to include commit 076e2b1, which requires the received username and password lengths in sppp_pap_input to match the configured credential lengths before calling bcmp.
2. Verify the actual running kernel or networking package revision rather than relying only on the displayed operating system version, because the confirmed fix is identified at commit level and no packaged release is supplied.
3. Until updating is possible, review and reduce the exposure of PPPoE interfaces using PAP, and restrict same-segment peers according to the applicable operational policy. This is a temporary risk-reduction measure, not a confirmed replacement for the fix.
4. After updating, recheck PAP authenticator configurations and monitor for anomalous PAP Auth-Requests that could indicate continued probing.

1. Inventory OpenBSD systems with PPPoE interfaces or sppp(4) configuration, then identify the source revision or installed package state containing fix commit 076e2b1.
2. Identify interfaces acting as PAP authenticators, especially PPPoE configurations using peerproto pap, peername, and peerkey.
3. If PPP-layer telemetry is available, review PAP Auth-Requests with name_len=0 and passwd_len=0, together with PAP_ACK responses or successful progression to IPCP negotiation. This is a technical check derived from the published flaw, not a universally confirmed IOC.
4. Review established PPPoE sessions from unexpected peers in the same broadcast domain. The absence of matching log evidence does not prove safety because logging coverage depends on configuration.