Jakub Zelenka

A criptografia de uma mensagem CMS para um certificado EC cujo ordem do grupo seja 1 pode fazer com que as funções `CMS encrypt()` ou `CMS encrypt ex()` entrem em loop indefinidamente. Isso ocorre porque a rotina de geração de chaves tenta repetidamente, sem limite, aguardar um escalar privado diferente de zero, o que não pode ser produzido se a ordem do grupo for 1. Um invasor que consiga fornecer um certificado de destinatário com parâmetros EC controlados para uma aplicação que realize a criptografia CMS pode desencadear esse comportamento, resultando em uma Negação de Serviço (DoS) ao consumir um núcleo de CPU até que o processo seja interrompido. As implementações TLS e QUIC do OpenSSL não são afetadas, e os módulos FIPS nas versões 3.0, 3.5, 4.0 e 4.1 não são impactados, pois rejeitam parâmetros de domínio EC explícitos arbitrários.

Um problema de corrupção de memória do tipo use-after-free existe no núcleo do interpretador PHP, especificamente no componente `session.upload progress`. A falha ocorre durante a análise da requisição quando o PHP registra o estado como pronto antes que todas as alocações de memória sejam concluídas. Se uma alocação falhar devido a erros de falta de memória (OOM), a função `longjmp()` é usada para abortar a requisição, mas alguns contextos não revertem adequadamente o estado incompleto, deixando a memória da requisição não inicializada. Procedimentos de limpeza subsequentes podem ler ou ramificar essa memória. Um invasor remoto não autenticado pode explorar isso enviando requisições HTTP POST especialmente formuladas para alcançar a execução remota de código (RCE). A exploração no mundo real foi observada em sistemas usando Apache mod php, onde invasores usaram uma cadeia HTTP de quatro estágios envolvendo exaustão de memória e divulgação de informações via cabeçalho `PHPSESSID` para ignorar o ASLR e executar comandos de shell como `/bin/sh`.

O PHP apresenta uma falha de use-after-free onde o estado global, o tratamento de erros, objetos e o estado de extensões podem não ser resetados corretamente ou podem ser repopulados após o reset. Isso ocorre porque alguns estados apontam para a memória de uma única solicitação; se um erro fatal interromper a fase de limpeza ou se o processo utilizar `longjmp()` para erros de falta de memória (OOM) para abortar o processamento da solicitação, o estado global pode referenciar a memória após ela ter sido liberada. Solicitações subsequentes podem ler ou tomar decisões com base nesse estado obsoleto antes de ser totalmente inicializado. Um invasor remoto não autenticado pode explorar essa condição, especificamente através do componente `session.upload progress` ou enviando uma solicitação POST especialmente formatada, para alcançar a execução remota de código (RCE). Este problema afeta o mod php e afeta condicionalmente o FPM através de caminhos de estágio de aplicação.

A função `phar tar number()` analisa o campo de tamanho octal de um cabeçalho TAR em um `uint32 t` sem verificação de estouro. Como o campo possui 11 dígitos octais e pode conter valores até 0x1FFFFFFFF, qualquer tamanho acima de 0xFFFFFFFF sofre um wrap silencioso. Isso faz com que o analisador pule um número incorreto de blocos de dados e interprete o conteúdo do arquivo controlado por um invasor como o próximo cabeçalho TAR, permitindo que um arquivo compactado manipulado injete entradas que o PharData reporta e extrai como se fossem genuínas.

No Windows, as APIs de sistema de arquivos e stream não rejeitam nomes de dispositivos reservados quando estes fazem parte de um caminho. Esses nomes reservados incluem CON, PRN, AUX, NUL, COM1 a COM9, LPT1 a LPT9, CONIN$ e CONOUT$. Consequentemente, um nome de arquivo controlado por um invasor pode alcançar a função `CreateFileW()` e abrir um dispositivo em vez de um arquivo comum. Esse comportamento pode causar a Negação de Serviço (DoS) ao bloquear ou travar requisições e esgotar os processos de trabalho.

O PHP contém um problema onde credenciais podem ser vazadas durante um redirecionamento ao usar curl. Isso ocorre quando a aplicação segue um redirecionamento para um host externo e inclui inadvertidamente credenciais de autenticação na requisição para o novo local.

O analisador de protocolo de fio do mysqlnd lê campos de pacotes do servidor sem verificar previamente se o pacote contém bytes suficientes. Isso permite que um servidor MySQL malicioso ou comprometido envie um pacote truncado, fazendo com que o cliente leia além do buffer do pacote. Este comportamento indefinido pode causar a interrupção do processo.

A verificação de acesso do cliente FastCGI para endereços IPv6 compara incorretamente apenas os primeiros 12 bytes de um endereço de 16 bytes. Isso faz com que a verificação `listen.allowed clients` corresponda a um prefixo /96 em vez do endereço exato. Um invasor que utilize um endereço que compartilhe os primeiros 96 bits com um endereço autorizado pode ignorar o controle de acesso e alcançar o endpoint FastCGI.

A verificação de peer do stream OpenSSL processa incorretamente a validação de certificados ao recorrer ao Common Name (CN) quando nenhuma entrada no `subjectAltName` (SAN) corresponde. De acordo com a RFC 6125, o CN deve ser ignorado se o certificado contiver qualquer identidade de serviço. Esse comportamento permite que um certificado confiável para um nome seja usado para personificar outro se o CN corresponder ao `peer name` solicitado, apesar de um DNS SAN não correspondente.

Os filtros de fluxo `convert.base64-encode`, `convert.quoted-printable-encode` e `convert.quoted-printable-decode` possuem um problema de manipulação de memória. Esses filtros utilizam a opção `line-break-chars`, cujo comprimento é rastreado independentemente da string real. Os construtores do filtro utilizam a função `pestrdup()`, que interrompe a string no primeiro byte NUL, mas mantém o comprimento original. Consequentemente, quando o filtro gera uma quebra de linha, ele lê além da alocação de memória truncada, resultando no vazamento de bytes adjacentes do heap para a saída do filtro.

A função `php openssl matches wildcard name()` em `ext/openssl/xp ssl.c` contém um underflow de inteiro no argumento de comprimento passado para `memchr()`. Isso ocorre quando um certificado de servidor TLS apresenta um nome curinga cujos caracteres literais são, juntos, mais longos do que o nome do host que está sendo verificado. Um servidor malicioso pode explorar isso para fazer com que o cliente PHP leia até `SIZE MAX` bytes além de uma alocação de heap. O caminho é acessível a partir de qualquer stream de cliente padrão, pois `verify peer name` é habilitado por padrão.

Nome do Software Vulnerável e Versões Afetadas: Versões do PHP até 8.1.31 Versões do PHP até 8.2.27 Versões do PHP até 8.3.18 Versões do PHP até 8.4.4 php7.4 Descrição: O problema refere-se ao wrapper HTTP de Streams no PHP. Recomendações: Para versões do PHP até 8.1.31, atualize para uma versão superior à 8.1.31. Para versões do PHP até 8.2.27, atualize para uma versão superior à 8.2.27. Para versões do PHP até 8.3.18, atualize para uma versão superior à 8.3.18. Para versões do PHP até 8.4.4, atualize para uma versão superior à 8.4.4. Para php7.4, considere atualizar para uma versão mais recente do PHP.

## Relatório de Vulnerabilidade **Nome do Software Vulnerável e Versões Afetadas** Versões do PHP 8.1.0 até 8.1.31 Versões do PHP 8.2.0 até 8.2.27 Versões do PHP 8.3.0 até 8.3.18 Versões do PHP 8.4.0 até 8.4.4 PHP 7.4 (Debian) **Descrição** O PHP é uma linguagem de script embutida em HTML comumente usada com o Servidor HTTP Apache. Existe uma vulnerabilidade no PHP devido a um tamanho limitado do buffer de localização ao analisar redirecionamentos HTTP. Isso pode levar ao truncamento incorreto da URL e ao redirecionamento para um local errado. **Recomendações** Versões do PHP 8.1.0 até 8.1.31: Atualize para a versão 8.1.32 ou posterior. Versões do PHP 8.2.0 até 8.2.27: Atualize para a versão 8.2.28 ou posterior. Versões do PHP 8.3.0 até 8.3.18: Atualize para a versão 8.3.19 ou posterior. Versões do PHP 8.4.0 até 8.4.4: Atualize para a versão 8.4.5 ou posterior. PHP 7.4 (Debian): Atualize para uma versão mais recente.

O problema está relacionado à validação insuficiente de caracteres de fim de linha em cabeçalhos fornecidos pelo usuário, o que pode impedir que certos cabeçalhos sejam enviados ou levar a que certos cabeçalhos sejam interpretados erroneamente. Isso pode potencialmente impactar o resultado e levar à negação de serviço ou problemas inesperados. A função `check has header()` é especificamente mencionada como estando relacionada a este problema, onde a falta de verificação de `r` poderia levar a um comportamento incorreto se apenas ` ` for usado no valor do cabeçalho.