O componente AUSF de livre 5 GC compara os valores de resposta de autenticação com os ajudantes de igualdade Go normais em vez de funções de comparação criptográfica em tempo constante. Dois fluxos de autenticação são afetados em `interna/ sbi/processador/ue_authentication.go`. 1. 5 A confirmação do G-AKA compara `RES*' e `XRES*' com `strings.EqualFold()'. 2. A confirmação do EAP-AKA compara o ` AT_MAC` com o `bytes.Equal()` e compara o `XRES` e o `RES` com o `==. Estas funções não são projetadas para serem comparadoras criptográficas em tempo constante e podem voltar mais cedo dependendo da localização do primeiro desvio. Além disso, o 5 O caminho de confirmação G- AKA registra tanto o ` res* ' recebido quanto o ` Xres*' esperado no nível INFO imediatamente antes de compará- los. O valor `XRES*` é material de autenticação e não deve ser escrito nos registros de aplicativos. O canal laterais do tempo foi confirmado como um problema de código, mas a exploração prática sobre HTTP não foi demonstrada no laboratório porque o sinal de nível de comparação é muito menor que o ruído HTTP/ SBI. O problema de registro `XRES*` é diretamente observável nos registros AUSF. Confirmado no `github.com/frete 5 gc/ausf` v 1.4.4 e principal atual a partir do mês de Maio 2026 análise.
#### 5 G- AKA: `RES*` / `XRES*'. Em ` Auth 5 gAkaComfirmRequestProcedure()`, o AUSF registra ambos os valores e os compara com ` strings.EqualFold()`: ``` go // internal/ sbi/processador/ue_authentication.go logger.Auth 5 gAkaLog.Infof("res*:%x\nXres*:%x\n", atualizarDatos de Confirmação.ResStar, ausfCurrentContext.XresStar). if strings.EqualFold(updateConfirmationData.ResStar, ausfCurrentContext.XresStar) { ausfCurrentContext.AuthStatus = modelos.AusfUeAuthenticationAuthResult_SUCCESS confirmadaDataRsp.AuthResult = modelos.AuthUeAuthenticationAuthResult_SUCCESS sucesso = logger verdadeiro.Auth 5 gAkaLog. Infoln(" 5 G AKA confirmação conseguiu") //... } ``` Para as strings hexadecimais ASCII, ` strings.EqualFold()` realiza uma comparação de caracteres que pode terminar quando um desconhecimento é encontrado. Não é uma comparação de tempo constante primitiva. A linha imediatamente antes da comparação é mais diretamente explorável: escreve `XresStar` para registros INFO. Qualquer operador, sidecar comprometido, coletor de logs, usuário SIEM ou processo local com acesso aos logs AUSF pode ler o valor de resposta esperado para tentativas de autenticação. #### EAP-AKA': `AT_MAC`, `XMAC`, `XRES` e `RES`. Em `EapAuthComfirmRequestProcedure()`, a AUSF calcula o MAC esperado e o compara com o ` AT_MAC` recebido usando `bytes.Equal()`: ```go K_autStr:= ausfCurrentContext.K_aut K_aut, _:= hex.DecodeString(K_autStr) XMAC:= CalcularAtMAC(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 = falso eapErrStr = "EAP-AKA' integrity check fail" } se o XRES for o mesmo que o XRES. `bytes.Equal()' não é especificado como uma comparação criptográfica em tempo constante. A comparação subsequente de string `XRES == RES` também não é de tempo constante. O primitivo correto para comparar etiquetas de autenticação e valores de resposta secreta em Go é `crypto/subtle.ConstantTimeCompare`, após validação e normalização do comprimento de entrada e codificação. O caso EAP-AKA' é mais difícil de explorar remotamente do que o 5 Caso G-AKA porque a comparação com `XRES == RES` é alcançada somente se ` AT_ MAC` for válida. Produzir um `AT_MAC` válido requer `K_aut` específico para a sessão. #### Evidência estática. Análise estática confirmada: - ` strings.EqualFold(updateConfirmationData.ResStar, ausfCurrentContext.XresStar)` no 5 Caminho de confirmação do G-AKA. - `logger.Auth 5 gAkaLog. Infof("res*:%x\nXres*:%x\n",...)` imediatamente antes da comparação. - `bytes.Equal(MAC, XMAC)` no caminho de confirmação do EAP- AKA. - `XRES == RES` no caminho de confirmação do EAP- AKA. - `crypto/ sutil` está ausente do código do processador de autenticação AUSF. ``` texto hallazgos/fisking 10 -hres- timing/ evidencia/ 20260526 - 090151 - análise- estatística/ halazgos/ verificação 11 - eap-mac- timing/ evidencia/ 20260526 - 094642 - análise- estatística/ ``.
#### 5 G-AKA temporização e registro de evidências. Um PoC temporário enviado 500 iterações por condição sobre o loopback HTTP/SBI: ````text Condição A: desajuste perto do início Condição B: desajuste no meio Condição C: desajuste perto do fim Condição D: partida completa ``` O sinal de posição do comparador não era distinguível do ruído HTTP. ``` texto Delta C-A: aproximadamente - 1.5 nós 2 - limiar de ruído de sigma: aproximadamente 557 resultado: sinal não limpo ``` Isto é consistente com a relação sinal- ruído esperado: a diferença de tempo do nível de comparação está no intervalo de nanosegundos, enquanto o caminho HTTP/ SBI adiciona centenas de microsegundos de variância. A mesma execução de laboratório confirmou que os registros AUSF incluem `XresStar` em texto simples ao nível do INFO. Isto não requer inferência estatística. ``` texto hallazgos/fisking 10 -hres- timing/ evidencia/ 20260526 - 093558 - timing- poc/ ``.
#### EAP-AKA' provas de tempo. Um PoC temporário enviado 500 iterações por condição contra o caminho de confirmação do EAP-AKA: ``` Texto A: primeiro byte MAC incorreto B: primeiro 8 Octets do MAC corretos C: correto do MAC, incorreto do XRES D: correto do MAC, correto do XRES ``` As medianas observadas estavam ao redor 464 - 467 Nós, e o sinal de tempo de nível HTTP não foi detetável: ``` Texto A: 466.6 nós B: 466.5 nós C: 464.2 nós D: 464.2 nós Delta D-A: aproximadamente - 2.4 nós 2 - limiar de ruído de sigma: aproximadamente 716 resultado: sinal não limpo ``` Isto confirma a limitação prática esperada de um ataque remoto de tempo HTTP. ``` texto hallazgos/fisking 11 - eap-mac- timing/ evidencia/ 20260526 - 103822 - timing- poc/ ``.
#### Referencia local da CPU para `bytes.Equal()`. Um microbenchmark direto Go sem a sobrecarga HTTP medida `bytes.Equal()` para 16 - valores de byte. Os dados brutos de referência mostraram um aumento monotônico conforme mais bytes principais correspondem. O delta mediano do ` N= 0 ` combinando bytes para ` N= 15 ` bytes correspondentes foi aproximadamente 0.31 ns, ou mais do que 20%. Isto confirma que o comparador local não é independente da posição no nível da CPU, mesmo que o sinal seja pequeno demais para ser explorado remotamente sobre HTTP em condições normais. ``` texto hallazgos/fisking 11 - eap-mac- timing/ evidencia/ 20260526 - 104842 - cpu- benchmark/ `` #### Confirmação do caminho de úproba. Os uprobes do Linux no processo AUSF ao vivo confirmaram que as solicitações atingem os caminhos de comparação relevantes: - O caminho de comparação do MAC é acertado tanto para tentativas de EAP- AKA falhando quanto para tentativas bem sucedidas. - O caminho de comparação do XRES é acertado somente quando a verificação do MAC passa. ``` texto hallazgos/fisking 11 - eap-mac- timing/ evidencia/ 20260526 - 053510 - ebpf- uprobe/ ``.
Existem duas classes de impacto. #### Valor sensível em registros. O 5 O caminho G-AKA registra o 'XRES*', o valor de resposta esperado, ao nível do INFO. Em implantações onde os registros AUSF são coletados centralmente ou são líveis por operadores de menores privilégios, agentes de infraestrutura, contêineres comprometidos ou sistemas de processamento de logs, isto expõe material de autenticação que deve permanecer interno ao procedimento de autenticação. A exploração exata depende se o atacante pode correlacionar o acesso ao log com um contexto de autenticação ativo e enviar a confirmação antes do contexto ser consumido ou falhado. Não importa, escrever `XRES*' para os registros de aplicativos é um manuseio inseguro do material de autenticação. #### Problema de endurecimento do canal lateral/criptografia. As comparações não constantes são questões de código reais e devem ser corrigidas, mas não demonstramos um oráculo de tempo remoto prático sobre HTTP/ SBI. O sinal comparador medido é muito pequeno em relação ao ruído HTTP no laboratório. O risco é maior em ambientes onde um atacante tem um ponto de medição de ruído inferior, co- residência local, capacidades de rastreamento do kernel, ou outro canal lateral que pode observar a comparação mais diretamente.
### Remediação sugerida. 1. Remover `XRES*', `RES*', `XRES', `RES', `K_aut', `AT_MAC' e material de autenticação derivado dos registros do INFO. Se o registro for necessário, registre apenas metadados, como o ID do contexto de autenticação, SUPI/SUCI em forma editada, resultado e classe de falha. 2. Substituir `strings.EqualFold()` e string ` ==` comparações para valores de autenticação com comparações em tempo constante. 3. Normalize codificações antes da comparação. Para valores codificados com hexadecifrar as duas entradas primeiro, validar os comprimentos esperados e, em seguida, comparar as fatias de byte de tamanho fixo. ```` vai resStar, erra 1:= hex.DecodeString(updateConfirmationData.ResStar) xresStar, err 2:= hex.DecodeString(ausfCurrentContext.XresStar). se errar 1 == err & zero 2 == Nil && len(resStar) == len(xresStar) && sutil.ConstantTimeCompare(resStar, xresStar)== 1 { // sucesso } outra coisa { // falha } ``` Exemplo para o MAC EAP-AKA'. ```` vai se len(MAC)!= len(XMAC).Sutil.ConstantTimeComparare(MAC, XMAC)!= 1 { eapOK = falso eapErrStr = falha na verificação da integridade do "EAP-AKA" } ```.
Exemplo para EAP-AKA' XRES. ```` ir res, errar 1:= hex.DecodeString(RES) xres, err 2:= hex.DecodeString(XRES) se errar 1 == err & zero 2 == Nil && len( res) == len(xres) && sutil.ConstantTimeCompare( res, xres) == 1 { // sucesso } ``` 4. Adicione testes unitários que garantam que os valores de autenticação não são escritos em registros. 5. Considere evitar uma segunda chamada de notificação UDM no 5 Caminho de falha do G-AKA se a primeira notificação de falha já reportar o resultado. No laboratório, o fracasso realizou duas chamadas UDM enquanto o sucesso realizou uma; isto cria uma diferença de tempo de sucesso/ falha grossa, embora esse resultado já esteja visível através da resposta da API. ### Nota de Antecedentes / não duplicação. Conhecido de graça recente 5 Problemas do GC AUSF, tais como CVE- 2026 - 33063 refere- se a diferentes modos de falha e caminhos de código. Este relatório diz respeito à comparação criptográfica e ao comportamento de registro em `intern/sbi/processor/ue_authentification.go`.
Registro de aconselhamento: GHSA- fp 46 - 6 vfw-gc 9 c. Identificadores relacionados: CVE- 2026 - 55785. Tempo: GitHub Advisory Database publicou este registro em 2026 - 08 - 28 T 22: 26: 16.000 Z e lista a sua última modificação como 2026 - 08 - 28 T 22: 26: 16.000 Z. Severidade: LOW. Dados de pontuação publicados: CVSS_V 3: CVSS: 3.1 /AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N. Software afetado e informações de versão: Go pacote github.com/free 5 gc/ausf — ECOSISTEM: introduzido 0, corrigido 1.4.5. Classificação e evidência: identificadores de fraqueza CWE- 208, CWE- 385, CWE- 532. O registro contém 3 suporte de referências nestes tipos: WEB, PACKAGE.