Falha de execução remota é encontrada no Apache OpenOffice

O Apache OpenOffice (AOO) está atualmente afetado por uma falha de execução remota de código, rastreada como CVE-2021-33035, que ainda não foi corrigida no lançamento oficial.

O pesquisador de segurança Eugene Lim ( @spaceraccoonsec ) revelou recentemente detalhes técnicos sobre uma falha de execução remota de código, rastreada como CVE-2021-33035, (CVE-2021-33035) que afeta o OpenOffice (AOO). Os especialistas revelaram a falha na conferência online HackerOne’s Hacktivity, depois que a empresa não conseguiu resolver a vulnerabilidade até 30 de agosto.

No momento em que este artigo foi escrito, a falha foi corrigida apenas com uma atualização de software beta e aguarda o lançamento oficial.

O Apache OpenOffice (AOO) está atualmente vulnerável a uma vulnerabilidade de execução remota de código e, embora o código-fonte do aplicativo tenha sido corrigido, a correção só foi disponibilizada como software beta e aguarda um lançamento oficial.

Um invasor pode acionar a falha enganando a vítima para que abra um arquivo .dbf especialmente criado.

Lim disse ao El Reg que o CVE-2021-33035 “é um estouro de buffer por um .dbf arquivo que substitui um ponteiro de retorno com um DEP [prevenção de execução de dados] e ASLR [randomização de layout de espaço de endereço] para finalmente executar comandos arbitrários pelo invasor”.

O pesquisador usou um fuzzer burro baseado em formato, chamado Peach Fuzzer, para descobrir vulnerabilidades em processadores DBF simples

O formato DBF é composto por duas seções principais, o cabeçalho e o corpo. O cabeçalho inclui um prefixo que descreve a versão do banco de dados dBase, o carimbo de data / hora da última atualização e outros metadados. O pesquisador ressaltou que o cabeçalho também especifica o comprimento de cada registro no banco de dados, o comprimento da estrutura do cabeçalho, o número de registros e os campos de dados em um registro. Os campos também incluem um descritor FieldLength. O corpo simplesmente contém todos os registros conforme descrito no cabeçalho.

Manipulando as fieldLength  ou  FieldType  valores ele era capaz de desencadear uma sobrecarga da memória intermédia.

O pesquisador conseguiu explorar a falha para abrir o arquivo no OpenOffice Calc e causar um travamento.

“Aqui, podemos ver um buffer nValue de tamanho sal_Int32 (4 bytes) sendo instanciado para um campo do tipo INTEGER. Em seguida, memcpy copia um buffer de tamanho nLen – que é um valor controlado pelo invasor – em nValue sem validar se nLen é menor ou igual a 4. Esse padrão foi repetido em vários tipos de dados. Isso poderia ser uma variação do estouro de buffer anterior? Modifiquei rapidamente meu gerador de carga anterior para o tipo de campo inteiro (I), aumentei o tamanho de fieldLength para maior que sal_Int32 e abri o arquivo no OpenOffice Calc. Eu tenho meu acidente! ” escreveu o Lim no Médio.

Apesar do sucesso parcial, o pesquisador percebeu que as proteções, como a randomização do layout do espaço de endereço (ASLR) e a Prevenção de Execução de Dados (DEP), evitavam a simples exploração do estouro de buffer.

Para contornar essas proteções, Lim importou a biblioteca de software libxml2 para analisar documentos XML porque ela não foi compilada com essas proteções.

“Eu joguei fora todos os gadgets ROP possíveis com a ferramenta rp do 0vercl0k e comecei a trabalhar. Eu rapidamente encontrei um problema: não importa como eu defini o valor fieldLength, parecia que o buffer sobrescrito estava limitado a cerca de 256 bytes. Isso impedia uma cadeia tradicional GetModuleHandleA> GetProcAddress> VirtualProtect, me forçando a me esforçar mais para atingir esse limite de tamanho. Comecei tentando algumas otimizações. Mudei meu esqueleto VirtualProtect final antes da cadeia ROP no buffer, dando-me um pouco mais de espaço para meus dispositivos ROP. Para meu pivô de pilha, usei um add codificado esp, 0x0C; ret; gadget para que eu não precise criar dinamicamente o deslocamento em minha cadeia. Por último, para fins de prova de conceito, decidi simplesmente carregar o WinExec para abrir o calc. ” concluiO especialista. “Isso reduziu o número de chamadas de função que eu precisava. Com um pouco de graxa de cotovelo, finalmente consegui fazer minha prova de conceito funcionar: ”

Fonte: https://securityaffairs.co/