Nora Dossche

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.

O cliente SOAP HTTP possui uma falha na maneira como gerencia o crescimento do buffer de resposta. O sistema utiliza uma verificação baseada em overflow de inteiro assinado, o que é considerado um comportamento indefinido e pode ser removido pelo compilador durante a otimização. Isso permite que um servidor SOAP malicioso force o cliente a alocar um buffer significativamente menor do que os dados que estão sendo gravados, resultando em um heap buffer overflow. Um heap buffer overflow ocorre quando dados são gravados além dos limites de um bloco de memória alocado no heap, podendo levar a falhas no sistema ou execução de código arbitrário.

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.

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.

Um problema de use-after-free existe no mecanismo de deduplicação de objetos da extensão SOAP, especificamente na função `soap add xml ref()`. O mecanismo armazena ponteiros para objetos PHP em um mapa global sem incrementar suas contagens de referência. Quando um nó apache:Map contém chaves duplicadas, a segunda entrada sobrescreve a primeira no mapa de resultado temporário, liberando o objeto PHP original enquanto um ponteiro obsoleto permanece. Uma referência href subsequente ao nó liberado pode copiar esse ponteiro pendente para o resultado. Como as alocações de string do PHP podem recuperar a região de memória liberada, um invasor remoto com controle sobre o corpo da requisição SOAP pode explorar isso para alcançar a execução remota de código.