Viktor Dukhovni

O processamento de um certificado contendo inúmeros pontos de distribuição de CRL `nameRelativeToCRLIssuer` pode causar um crescimento desproporcional do heap quando as extensões X.509 são armazenadas em cache. Um peer malicioso pode enviar um certificado manipulado que, embora permaneça abaixo do limite de tamanho aceito de aproximadamente 100 KiB, desencadeia a alocação de várias centenas de MiB de memória residente durante um handshake TLS padrão. Essa alocação excessiva de memória pode levar a uma pressão significativa de memória e a uma possível Negação de Serviço, podendo travar o cliente ou o servidor se ocorrerem múltiplas conexões simultâneas.

A geração de assinatura SM2 utiliza aritmética de tempo não constante em valores secretos, criando um canal lateral de temporização. O processo calcula o valor da assinatura usando operações BIGNUM de tempo variável na chave privada e no nonce secreto, o que significa que o tempo necessário para produzir uma assinatura depende desses valores secretos. Um invasor capaz de medir os tempos de assinatura pode obter informações sobre o nonce secreto por assinatura, o que pode levar à recuperação da chave privada por meio de um ataque de rede (lattice) ou do Problema do Número Oculto (Hidden Number Problem).

Uma desreferenciação de ponteiro NULL pode ocorrer em configurações de servidor ou cliente onde as Chaves Públicas Brutas (RPKs) do RFC7250 estão habilitadas e apenas uma chave privada é configurada localmente sem um certificado associado. Isso acontece quando um peer remoto solicita chaves públicas brutas e inclui a extensão TLS `signature algorithms cert`. Este problema pode levar a uma Negação de Serviço (DoS) devido ao encerramento abrupto da aplicação. Uma desreferenciação de ponteiro NULL é um erro de software onde o programa tenta ler ou gravar em um endereço de memória que é NULL, normalmente causando a falha da aplicação.

Ao utilizar a cifra AES-OCB com a interface one-shot `EVP Cipher()`, o vetor de inicialização (IV) fornecido pela aplicação é silenciosamente descartado. Isso faz com que cada mensagem criptografada com a mesma chave utilize o mesmo nonce efetivo, resultando na reutilização de (chave, nonce) e perda de confidencialidade. Se o mesmo caminho for utilizado para calcular a tag de autenticação, a tag dependerá apenas do par (chave, IV) e não do texto simples ou do texto cifrado, permitindo a falsificação universal de qualquer texto cifrado a partir de uma única mensagem capturada. Isso ocorre porque o manipulador one-shot não descarrega o IV no contexto OCB, diferentemente do manipulador de streaming. Se `EVP EncryptFinal ex()` for posteriormente utilizado para obter a tag de autenticação, a configuração diferida do IV limpa o checksum acumulado que deveria ter sido processado sobre o texto simples.

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 configuração incomum de clientes executando autenticação de servidor baseada em DANE TLSA, quando combinada com registros DANE TLSA de servidor incomuns, pode resultar em um uso após liberação e/ou liberação dupla no lado do cliente. Um uso após liberação pode levar à corrupção de dados, travamentos ou execução de código arbitrário. O problema afeta clientes que usam registros TLSA com os usos de certificado PKIX-TA(0/PKIX-EE(1)) e DANE-TA(2). Clientes que tratam os registros PKIX TLSA como inutilizáveis ou suportam apenas os usos PKIX não são vulneráveis. O cliente também deve se comunicar com um servidor que publique um conjunto de registros TLSA RR com ambos os tipos de registros TLSA.

Um estouro de inteiro assinado ocorre ao dimensionar o buffer de destino para a saída Unicode na função `ASN1 mbstring ncopy()`, o que pode levar a um estouro de buffer de heap. Isso acontece em `ASN1 mbstring copy()` e `ASN1 mbstring ncopy()` porque o tamanho do destino para a saída Unicode é computado como um inteiro assinado. Especificamente, o cálculo transborda quando a entrada atinge aproximadamente 2^30 caracteres através de um deslocamento à esquerda da contagem de caracteres de entrada para BMPSTRING (UTF-16) e UNIVERSALSTRING (UTF-32), ou somando as contagens de bytes por caractere para UTF8STRING. No pior cenário envolvendo UNIVERSALSTRING com 2^30 caracteres, o tamanho retorna a zero, resultando em uma alocação mínima que é subsequentemente sobrescrita por vários gigabytes de dados. Isso pode levar a um travamento, comportamento indefinido ou execução de código controlado por um invasor. O acionamento deste problema requer que uma aplicação chame `ASN1 mbstring copy()` ou `ASN1 mbstring ncopy()` diretamente, ou registre um tipo de string personalizado via `ASN1 STRING TABLE add()` com entrada controlada por um invasor de meio gigabyte ou mais.

Uma truncagem de inteiro no decodificador ASN.1 ocorre ao processar uma estrutura ASN.1 codificada em DER manipulada com um elemento primitivo que excede 2 gigabytes de comprimento. Este problema afeta especificamente plataformas Unix e semelhantes a Unix de 64 bits. O comprimento truncado pode ser tratado como uma solicitação para escanear o conteúdo binário em busca de um byte zero terminador, levando a um over-read de buffer de heap. Isso pode resultar em um Denial of Service (Negação de Serviço) ao travar a aplicação ou fazer com que a memória além do buffer de entrada seja carregada no objeto ASN.1 decodificado. Aplicações que passam dados fornecidos por atacantes para funções de decodificação como "d2i X509()", "d2i PKCS7()" ou qualquer outra função "d2i *" são afetadas.

An issue exists in OpenSSL TLS 1.3 servers where the server may fail to negotiate the expected preferred key exchange group when its key exchange group configuration includes the default by using the 'DEFAULT' keyword. This can result in a less preferred key exchange being used, even when a more secure group is supported by both the client and server, if the preferred group was not included in the client's initial keyshare predictions. This is particularly relevant with new hybrid post-quantum groups, where the client might defer their use until specifically requested by the server. The root cause is an implementation defect that causes the 'DEFAULT' list to lose its 'tuple' structure, treating all server-supported groups as a single sufficiently secure tuple, and preventing the server from sending a Hello Retry Request (HRR) when a more preferred group is mutually supported. The issue does not affect OpenSSL FIPS modules.

O OpenSSL contém vulnerabilidades devido a problemas de leitura e escrita fora dos limites. Especificamente, uma leitura e escrita fora dos limites pode ocorrer ao descriptografar mensagens CMS criptografadas usando criptografia baseada em senha, potencialmente levando a uma falha ou corrupção de memória. Além disso, uma leitura fora dos limites pode ocorrer nas funções da API do cliente HTTP quando a variável de ambiente 'no proxy' está definida e a porção do host do componente de autoridade da URL HTTP é um endereço IPv6. Os módulos FIPS nas versões 3.5, 3.4, 3.3, 3.2, 3.1 e 3.0 do OpenSSL não são afetados.

Clientes que utilizam Chaves Públicas Brutas (RPKs) do RFC7250 para autenticar um servidor podem não notar que o servidor não foi autenticado. Isso ocorre porque os handshakes TLS e DTLS não são abortados conforme esperado quando o modo de verificação `SSL VERIFY PEER` está configurado. Este problema pode permitir ataques de man-in-the-middle se o cliente depender da falha do handshake para identificar uma incompatibilidade de autenticação. As RPKs são desativadas por padrão; o problema só surge quando os clientes habilitam explicitamente o uso de RPK e o servidor envia uma RPK em vez de uma cadeia de certificados X.509. Clientes que verificam o resultado chamando a função `SSL get verify result()` e tomam as medidas adequadas não são afetados. Os módulos FIPS nas versões 3.0 a 3.4 não são impactados.

A ferramenta de linha de comando 'openssl dgst' trunca silenciosamente os dados de entrada para 16 MB ao usar algoritmos de assinatura one-shot e reporta sucesso em vez de um erro. Isso pode levar o usuário a acreditar que um arquivo inteiro foi autenticado, quando os dados finais além de 16 MB permanecem não autenticados. O problema afeta apenas o comportamento da ferramenta de linha de comando e não impacta verificadores que processam a mensagem completa usando APIs da biblioteca. Algoritmos de digest em streaming para 'openssl dgst' e usuários da biblioteca também não são afetados. O problema ocorre ao usar algoritmos de assinatura one-shot, como Ed25519, Ed448 ou ML-DSA. A ferramenta trunca a entrada para os primeiros 16 MB e continua sem sinalizar um erro, criando uma lacuna de integridade onde bytes finais podem ser modificados sem detecção, se tanto a assinatura quanto a verificação forem realizadas usando o mesmo caminho de código afetado.

O problema está relacionado a uma negação de serviço nas verificações de nomes X.509. Aplicativos que realizam verificações de nomes de certificados, como clientes TLS que verificam certificados de servidor, podem tentar ler um endereço de memória inválido ao comparar o nome esperado com um nome alternativo do sujeito `otherName` de um certificado X.509. Isso pode resultar em uma exceção que encerra o programa aplicativo. A validação básica da cadeia de certificados não é afetada, e a negação de serviço só pode ocorrer quando o aplicativo também especifica um nome DNS, endereço de e-mail ou endereço IP esperado. Os servidores TLS geralmente não são afetados, e a gravidade do problema é Moderada.

Nome do software vulnerável e versões afetadas: Versões do OpenSSL anteriores à 3.3.3 Descrição: O problema decorre do uso de APIs de curva elíptica GF(2^m) de baixo nível com valores explícitos não confiáveis para o polinômio de campo, levando a leituras ou gravações de memória fora dos limites. Isso pode causar uma falha no aplicativo ou, potencialmente, permitir a execução remota de código. No entanto, a probabilidade de um aplicativo vulnerável é baixa, já que a maioria dos protocolos envolvendo criptografia de curva elíptica suporta apenas “curvas nomeadas” ou especifica uma codificação X9.62 de curvas binárias (GF(2^m)) que não podem representar valores de entrada problemáticos. As APIs afetadas incluem `EC GROUP new curve GF2m()`, `EC GROUP new from params()` e várias funções de suporte `BN GF2m *()`. Recomendações: Para versões anteriores à 3.3.3, atualize para a versão 3.3.3 ou posterior para resolver o problema. Como solução temporária, considere restringir o uso das funções vulneráveis `EC GROUP new curve GF2m()` e `EC GROUP new from params()`, bem como das funções de suporte `BN GF2m *()`, até que um patch esteja disponível. Evite usar parâmetros de curva binária explícita “exótica” (GF(2^m)) que possam representar polinômios de campo inválidos com um termo constante zero.

A read buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. This occurs after certificate chain signature verification and requires either a CA to have signed the malicious certificate or for the application to continue certificate verification despite failure to construct a path to a trusted issuer. The read buffer overrun might result in a crash, which could lead to a denial of service attack. In theory, it could also result in the disclosure of private memory contents, such as private keys or sensitive plaintext, although no working exploit leading to memory contents disclosure is known at the time of release of this advisory. In a TLS client, this can be triggered by connecting to a malicious server. In a TLS server, this can be triggered if the server requests client authentication and a malicious client connects.

A função da API pública BIO new NDEF é uma função auxiliar usada para transmitir dados ASN.1 por meio de um BIO. Ela é usada principalmente internamente no OpenSSL para oferecer suporte aos recursos de streaming SMIME, CMS e PKCS7, mas também pode ser chamada diretamente por aplicativos de usuários finais. A função recebe um BIO do chamador, acrescenta um novo filtro BIO f asn1 à sua frente para formar uma cadeia BIO e, em seguida, retorna o novo cabeçalho da cadeia BIO ao chamador. Sob certas condições, por exemplo, se uma chave pública do destinatário CMS for inválida, o novo filtro BIO é liberado e a função retorna um resultado NULL indicando uma falha. No entanto, nesse caso, a cadeia BIO não é limpa adequadamente e o BIO passado pelo chamador ainda retém ponteiros internos para o filtro BIO liberado anteriormente. Se o chamador então chamar BIO pop() no BIO, ocorrerá um uso após liberação. Isso provavelmente resultará em uma falha do sistema. Esse cenário ocorre diretamente na função interna B64 write ASN1(), o que pode fazer com que BIO new NDEF() seja chamado e, subsequentemente, chame BIO pop() no BIO. Outras funções da API pública que podem ser afetadas por isso incluem i2d ASN1 bio stream, BIO new CMS, BIO new PKCS7, i2d CMS bio stream e i2d PKCS7 bio stream.

Um estouro de buffer pode ser desencadeado na verificação de certificados X.509, especificamente na verificação de restrições de nome. Isso ocorre após a verificação da assinatura da cadeia de certificados e requer que uma CA tenha assinado um certificado malicioso ou que um aplicativo continue a verificação do certificado apesar da falha em construir um caminho para um emissor confiável. Um invasor pode criar um endereço de e-mail malicioso em um certificado para causar um estouro de buffer com um número arbitrário de bytes contendo o caractere `.` (decimal 46) na pilha. Esse estouro de buffer pode resultar em uma falha (causando uma negação de serviço). Em um cliente TLS, isso pode ser desencadeado pela conexão a um servidor malicioso. Em um servidor TLS, isso pode ser desencadeado se o servidor solicitar autenticação do cliente e um cliente malicioso se conectar.

The issue is related to the ` krb5 extract ticket()` function, which obtains service-principal names in a way that violates the Kerberos 5 protocol specification. This allows remote attackers to impersonate services with Orpheus' Lyre attacks. The problem arises because the function uses the unencrypted version of the service name stored in `ticket` instead of the encrypted version stored in `enc part`. This provides an opportunity for successful server impersonation and other attacks.

A security-feature bypass issue allows attackers to affect the system. This issue is related to Kerberos failing to prevent tampering with the SNAME field during ticket exchange.

The issue is related to the lack of protection for internal data in the Tcl component of the operating system. It can be exploited by a remote attacker to obtain sensitive information by leveraging SSLv2 support.