OpenEXR corrigiu 15 vulnerabilidades na leitura de ficheiros EXR

Os desenvolvedores da biblioteca OpenEXR lançaram a 31 de outubro a versão de correções 3.5.3. Esta corrige 15 vulnerabilidades, das quais 10 aguardam a atribuição de números CVE. Quase todas são acionadas ao ler um ficheiro EXR danificado ou especialmente preparado: trata-se de estouros de buffer e de escritas fora da memória alocada. Segundo os autores do lançamento, vários destes erros permitiam executar código remotamente.

Para os estúdios é um risco concreto. As sequências EXR chegam de prestadores externos, de clientes, de arquivos alheios e de serviços de partilha de ficheiros, e são abertas, em regra, sem qualquer verificação à parte. Para o ataque funcionar não é preciso executar o ficheiro: basta que um programa baseado numa versão vulnerável do OpenEXR tente lê-lo. No mesmo dia, pouco antes da 3.5.3, saiu a versão 3.4.17 para o ramo anterior. Corrige nove destas vulnerabilidades, as que dizem respeito ao ramo 3.4, pelo que os utilizadores da 3.4 podem atualizar sem passar para a 3.5.

Onde estavam os erros

A lista de correções abrange quase todos os caminhos pelos quais um EXR chega à memória:

• compressão DWAA/DWAB: cinco pontos, incluindo uma escrita fora dos limites da memória no descodificador, uma fuga de dados não inicializados quando o fluxo comprimido é curto e um acesso a apontador nulo com canais subamostrados;
• compressão B44: um estouro no cálculo do tamanho do bloco descomprimido, que os autores assinalam expressamente como possibilidade de execução remota de código, e um erro no codificador com subamostragem;
• imagens deep: dois erros ao descomprimir dados deep comprimidos com ZSTD e um estouro ao regravar ficheiros deep em mosaico. O último, na avaliação dos desenvolvedores, pode ser consequência de uma correção incompleta de um erro antigo;
• HTJ2K: um acesso incorreto à memória durante a descodificação;
• ficheiros multiparte (multipart): um cabeçalho sem limites de tamanho podia obrigar o programa a analisá-lo com um custo quadrático de tempo e recursos;
• módulo Python do OpenEXR: um estouro de buffer quando coincidem os nomes de dois grupos de canais RGB e uma escrita num deslocamento escolhido pelo atacante na interface obsoleta de leitura de canais;
• atributos do cabeçalho: um acesso a memória já liberada se o nome de um canal tiver mais de 31 bytes e um estouro devido a uma lista adicional de canais não verificada.

O erro que os desenvolvedores associam expressamente à execução remota de código é descrito assim nas notas do lançamento:

«Escrita fora dos limites da heap devido a um estouro de inteiro no cálculo do tamanho descomprimido de um bloco B44 — execução remota de código no OpenEXRCore».

Na 3.5.3 não há funcionalidades novas nem outras alterações de comportamento, exceto a correção de uma regressão com as imagens deep (ver abaixo). O utilizador pode notar mais uma coisa: a biblioteca verifica agora com maior rigor os dados de entrada e rejeita ficheiros incorretos. Todo o conjunto de testes passa agora sem erros sob verificações de depuração que detetam erros de gestão de memória, comportamento indefinido e condições de corrida entre threads. A lista completa de alterações está no ficheiro CHANGES.md.

O que mais entrou nesta versão

• Leitura de imagens deep em sistemas big-endian. Desde a versão 3.4.14, nessas máquinas a biblioteca obtinha uma tabela de contagem de amostras incorreta por causa de um erro de ordem de bytes. Os sistemas little-endian não eram afetados. Esta correção também está na 3.4.17.
• Suporte para Python 3.15 para quem escreve scripts de pipeline num interpretador recente.
• Os utilitários exrmetrics, exrmultipart e exrcheck receberam correções de diagnóstico e de correção, tal como os principais caminhos de descompressão. O autor destas correções é Alex Khal.
• Plataformas. Foram corrigidos erros antigos de compilação e de testes em Linux de 32 bits (i686) e s390x, problemas de compilação em macOS anterior a 10.15 e powerpc, bem como o arranque em Windows 7.

Quem deve atualizar e com que urgência

A julgar pela composição das vulnerabilidades, a maior parte dos problemas está em código que existe há muito tempo. Dos 15 pontos, apenas dois estão relacionados com a compressão ZSTD, que surgiu na linha 3.5 com o lançamento da 3.5.0 em setembro; o maior ganho dava-se então nos dados deep, em que os ficheiros ficavam 20–30% mais pequenos do que com ZIPS. Os restantes erros dizem respeito a DWA, B44, ficheiros deep em mosaico, à análise de cabeçalhos e ao módulo Python. Por isso, abdicar dos novos formatos de compressão provavelmente pouco traz: também estava vulnerável a parte da biblioteca por onde passam há muito os renders e a composição.

A regressão com as imagens deep diz respeito a um círculo restrito de máquinas. As estações de trabalho típicas em x86 e ARM funcionam em little-endian e não a notavam. Esta correção é mais importante para quem compila o OpenEXR para hardware de servidor e mais raro.

A maioria dos artistas não instala o OpenEXR diretamente: a biblioteca é integrada nas suas próprias compilações pelos desenvolvedores de pacotes DCC, de programas de composição, de motores de render e de visualizadores. A correção chegará aos postos de trabalho quando esses fornecedores lançarem atualizações; os prazos não são indicados nos materiais do lançamento. Podem agir por conta própria os TD de pipeline e os estúdios que têm ferramentas próprias baseadas no módulo Python do OpenEXR ou compilações próprias da biblioteca. Para esses, faz sentido passar para a 3.5.3 ou a 3.4.17 em primeiro lugar, sobretudo se as ferramentas processarem ficheiros de fontes externas.

De onde lhe chegam com mais frequência os ficheiros EXR alheios?

• De prestadores externos
• De clientes