Threats Tagged 'cve-2026-55785'

### 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 IN