Nas situações em que um atacante recebe uma notificação automatizada do sucesso ou falha de uma tentativa de descriptografia, o atacante, após enviar um número muito grande de mensagens a serem descriptografadas, pode recuperar uma chave de criptografia transportada CMS/PKCS7 ou descriptografar qualquer mensagem criptografada RSA que foi criptografada com a chave pública RSA, usando um ataque de padding oracle Bleichenbacher. Os aplicativos não serão afetados se eles usarem um certificado junto com a chave RSA privada para as funções CMS_decrypt() ou PKCS7_decrypt() para selecionar as informações corretas do destinatário a descriptografar.
Tag: The OpenSSL Project
ASA-2019-00536 – OpenSSL: Proteção fork
O OpenSSL 1.1.1 introduziu um reescrito gerador de números aleatórios (RNG). Isso pretendia incluir proteção no caso de uma chamada do sistema fork() para garantir que os processos pai e filho não compartilhassem o mesmo estado RNG. No entanto, essa proteção não estava sendo usada no caso padrão. Uma mitigação parcial para esse problema é que a saída de um timer de alta precisão é misturada no estado RNG, para que a probabilidade de um estado de compartilhamento de processos pai e filho seja significativamente reduzida. Se um aplicativo já chamar OPENSSL_init_crypto() explicitamente usando OPENSSL_INIT_ATFORK, esse problema não ocorrerá.
ASA-2019-00535 – OpenSSL: ECDSA timing attack remoto
Normalmente, nos grupos OpenSSL EC sempre há um co-fator presente e isso é usado em caminhos de código resistentes a side channel. No entanto, em alguns casos, é possível construir um grupo usando parâmetros explícitos (em vez de usar uma curva nomeada). Nesses casos, é possível que esse grupo não tenha o cofator presente. Isso pode ocorrer mesmo onde todos os parâmetros correspondem a uma curva nomeada conhecida. Se essa curva for usada, o OpenSSL retornará a caminhos de código nao resistentes a side channel, o que pode resultar em recuperação total de chave durante uma operação de assinatura ECDSA. Para ficar vulnerável, o atacante precisa ter a capacidade de cronometrar a criação de um grande número de assinaturas, onde parâmetros explícitos sem co-fator presente estão sendo usados por um aplicativo que usa libcrypto.
ASA-2019-00477 – OpenSSL: Windows builds com path inseguro por padrão
O OpenSSL possui padrões internos para uma estrutura de diretórios onde se pode encontrar um arquivo de configuração, bem como certificados usados para verificação no TLS. Esse diretório é mais comumente referido como OPENSSLDIR e é configurável com as opções de configuração –prefix / –openssldir. Para as versões 1.1.0 e 1.1.1 do OpenSSL, os destinos de configuração do mingw assumem que os programas e bibliotecas resultantes estejam instalados em um ambiente semelhante ao Unix e que o prefixo padrão para instalação do programa, bem como para OPENSSLDIR, seja ‘/usr/local’. No entanto, programas mingw são programas do Windows e, como tal, encontram-se apontando para subdiretórios de 'C:/usr/local', que podem ser modificados, o que permite que usuários não confiáveis modifiquem a configuração padrão do OpenSSL, insiram certificados CA, modifiquem (ou mesmo substituam) módulos de engines existentes, etc.