GHSA-fp46-6vfw-gc9c free5GC AUSF uses non-constant-time authentication comparisons and logs XRES* in 5G-AKA

• Go github.com/free5gc/ausf: < 1.4.5 → fixed in 1.4.5

Summary The AUSF component of free5GC compares authentication response values with normal Go equality helpers instead of constant-time cryptographic comparison functions. Two authentication flows are affected in `internal/sbi/processor/ue_authentication.go`: 1. 5G-AKA confirmation compares `RES*` and `XRES*` with `strings.EqualFold()`. 2. EAP-AKA' confirmation compares `AT_MAC` with `bytes.Equal()` and compares `XRES` and `RES` with `==`. These functions are not designed to be constant-time cryptographic comparators and may return earlier depending on the location of the first mismatch. Additionally, the 5G-AKA confirmation path logs both the received `res*` and the expected `Xres*` at INFO level immediately before comparing them. The `XRES*` value is authentication material and should not be written to application logs. The timing side channel was confirmed as a code issue, but practical exploitation over HTTP was not demonstrated in the lab because the comparator-level signal is much smaller than HTTP/SBI noise. The `XRES*` logging issue is directly observable in AUSF logs. Confirmed on `github.com/free5gc/ausf` v1.4.4 and current main as of the May 2026 analysis. Details 5G-AKA: `RES*` / `XRES*` In `Auth5gAkaComfirmRequestProcedure()`, the AUSF logs both values and then compares them with `strings.EqualFold()`: ```go // internal/sbi/processor/ue_authentication.go logger.Auth5gAkaLog.Infof("res*: %x\nXres*: %x\n", updateConfirmationData.ResStar, ausfCurrentContext.XresStar) if strings.EqualFold(updateConfirmationData.ResStar, ausfCurrentContext.XresStar) { ausfCurrentContext.AuthStatus = models.AusfUeAuthenticationAuthResult_SUCCESS confirmDataRsp.AuthResult = models.AusfUeAuthenticationAuthResult_SUCCESS success = true logger.Auth5gAkaLog.Infoln("5G AKA confirmation succeeded") // ... } ``` For hexadecimal ASCII strings, `strings.EqualFold()` performs a character comparison that can terminate when a mismatch is found. It is not a constant-time comparison primitive. The line immediately before the comparison is more directly exploitable: it writes `XresStar` to INFO logs. Any operator, compromised sidecar, log collector, SIEM user, or local process with access to AUSF logs can read the expected response value for authentication attempts. EAP-AKA': `AT_MAC`, `XMAC`, `XRES`, and `RES` In `EapAuthComfirmRequestProcedure()`, the AUSF computes the expected MAC and compares it with the received `AT_MAC` using `bytes.Equal()`: ```go K_autStr := ausfCurrentContext.K_aut K_aut, _ := hex.DecodeString(K_autStr) XMAC := CalculateAtMAC(K_aut, decodeEapAkaPrimePkt.MACInput) MAC := decodeEapAkaPrimePkt.Attributes[ausf_context.AT_MAC_ATTRIBUTE].Value XRES := ausfCurrentContext.XRES RES := hex.EncodeToString(decodeEapAkaPrimePkt.Attributes[ausf_context.AT_RES_ATTRIBUTE].Value) if !bytes.Equal(MAC, XMAC) { eapOK = false eapErrStr = "EAP-AKA' integrity check fail" } else if XRES == RES { logger.AuthELog.Infoln("Correct RES value, EAP-AKA' auth succeed") // ... } ``` `bytes.Equal()` is not specified as a constant-time cryptographic comparison. The subsequent `XRES == RES` string comparison is also not constant-time. The correct primitive for comparing authentication tags and secret response values in Go is `crypto/subtle.ConstantTimeCompare`, after validating and normalizing input length and encoding. The EAP-AKA' case is harder to exploit remotely than the 5G-AKA case because the `XRES == RES` comparison is reached only if `AT_MAC` is valid. Producing a valid `AT_MAC` requires session-specific `K_aut`. Evidence Static evidence Static analysis confirmed: • `strings.EqualFold(updateConfirmationData.ResStar, ausfCurrentContext.XresStar)` in the 5G-AKA confirmation path. • `logger.Auth5gAkaLog.Infof("res*: %x\nXres*: %x\n", ...)` immediately before the comparison. • `bytes.Equal(MAC, XMAC)` in the EAP-AKA' confirmation path. • `XRES == RES` in the EAP-AKA' confirmation path. • `crypto/subtle` is absent from the AUSF authentication processor code. Internal evidence: ```text hallazgos/finding10-hres-timing/evidencia/20260526-090151-static-analysis/ hallazgos/finding11-eap-mac-timing/evidencia/20260526-094642-static-analysis/ ``` 5G-AKA timing and logging evidence A timing PoC sent 500 iterations per condition over loopback HTTP/SBI: ```text Condition A: mismatch near the start Condition B: mismatch in the middle Condition C: mismatch near the end Condition D: full match ``` The comparator-position signal was not distinguishable from HTTP noise: ```text Delta C-A: approximately -1.5 us 2-sigma noise threshold: approximately 557 us Result: SIGNAL NOT CLEAR ``` This is consistent with the expected signal-to-noise ratio: the comparator-level timing difference is in the nanosecond range, while the HTTP/SBI path adds hundreds of microseconds of variance. The same lab run confirmed that AUSF logs include `XresStar` in plaintext at INFO level. This does not require statistical inference. Internal evidence: ```text hallazgos/finding10-hres-timing/evidencia/20260526-093558-timing-poc/ ``` EAP-AKA' timing evidence A timing PoC sent 500 iterations per condition against the EAP-AKA' confirmation path: ```text A: first MAC byte incorrect B: first 8 MAC bytes correct C: MAC correct, XRES incorrect D: MAC correct, XRES correct ``` Observed medians were all around 464-467 us, and the HTTP-level timing signal was not detectable: ```text A: 466.6 us B: 466.5 us C: 464.2 us D: 464.2 us Delta D-A: approximately -2.4 us 2-sigma noise threshold: approximately 716 us Result: SIGNAL NOT CLEAR ``` This confirms the expected practical limitation of a remote HTTP timing attack. Internal evidence: ```text hallazgos/finding11-eap-mac-timing/evidencia/20260526-103822-timing-poc/ ``` Local CPU benchmark for `bytes.Equal()` A direct Go microbenchmark without HTTP overhead measured `bytes.Equal()` for 16-byte values. The raw benchmark data showed a monotonic increase as more leading bytes matched. The median delta from `N=0` matching bytes to `N=15` matching bytes was roughly 0.31 ns, or more than 20%. This confirms that the local comparator is not position-independent at CPU level, even though the signal is too small to exploit remotely over HTTP in normal conditions. Internal evidence: ```text hallazgos/finding11-eap-mac-timing/evidencia/20260526-104842-cpu-benchmark/ ``` Uprobe path confirmation Linux uprobes on the live AUSF process confirmed that requests reach the relevant comparison paths: • MAC comparison path is hit for both failing and successful EAP-AKA' attempts. • XRES comparison path is hit only when MAC verification passes. Internal evidence: ```text hallazgos/finding11-eap-mac-timing/evidencia/20260526-053510-ebpf-uprobe/ ``` Impact There are two impact classes. Sensitive value in logs The 5G-AKA path logs `XRES*`, the expected response value, at INFO level. In deployments where AUSF logs are collected centrally or are readable by lower-privileged operators, infrastructure agents, compromised containers, or log-processing systems, this exposes authentication material that should remain internal to the authentication procedure. The exact exploitability depends on whether the attacker can correlate log access with an active authentication context and submit the confirmation before the context is consumed or failed. Regardless, writing `XRES*` to application logs is an unsafe handling of authentication material. Timing side channel / cryptographic hardening issue The non-constant-time comparisons are real code issues and should be fixed, but we did not demonstrate a practical remote timing oracle over HTTP/SBI. The measured comparator signal is too small relative to HTTP noise in the lab. The risk is higher in environments where an attacker has a lower-noise measurement point, local co-residency, kernel tracing capabilities, or another side channel that can observe the comparison more directl…