Norbert Pócs

Quando a função `EVP PKEY derive set peer()` é chamada com uma chave de peer DHX (X9.42), o software não verifica adequadamente a associação ao subgrupo. Especificamente, a verificação `Y^q ≡ 1 (mod p)` é realizada utilizando o parâmetro `q` fornecido pelo peer, em vez do parâmetro `q` da chave local. Embora outros parâmetros de domínio sejam comparados com a chave privada, o valor de `q` não é comparado. Isso permite que um peer malicioso apresente uma chave X9.42 com os parâmetros `p` e `g` da vítima, um `q` forjado igual a `r` (um fator primo pequeno do cofator `(p−1)/q local`) e um valor público `Y` de ordem `r`. Isso ignora as verificações e resulta em um segredo compartilhado com apenas `r` valores distintos, vazando a chave privada módulo `r`. Ao repetir este processo para cada fator primo pequeno do cofator e combinar os resultados via Teorema Chinês do Resto (CRT), um invasor pode recuperar a chave privada completa. Isso é conhecido como um ataque de Lim–Lee ou de confinamento de subgrupo pequeno.

Uma falha existe no tratamento de arquivos PKCS#12 maliciosamente criados ao usar a API `PKCS12 get friendlyname()`. Especificamente, processar um arquivo PKCS#12 com um nome amigável BMPString (UTF-16BE) contendo pontos de código BMP não ASCII pode levar a uma escrita de um byte antes do buffer alocado. Essa escrita fora dos limites pode causar corrupção de memória, possivelmente resultando em Negação de Serviço. O problema decorre de um cálculo incorreto de capacidade dentro da função `bmp to utf8()` durante o processo de conversão de UTF-16 para UTF-8, especificamente ao lidar com pontos de código BMP acima de U+07FF. A função `OPENSSL uni2utf8()` está envolvida nessa conversão. A vulnerabilidade é acionada ao analisar arquivos PKCS#12 controlados pelo atacante por meio da API pública `PKCS12 get friendlyname()`. Os módulos FIPS nas versões 3.6, 3.5, 3.4, 3.3 e 3.0 não são afetados.