Calc do LibreOffice/OpenOffice permite execução de código remoto ao abrir folhas com ODB/JDBC

Autor: Publicada 6 min de lectura 5 leituras

As imagens deste artigo foram geradas com inteligência artificial. Como publicamos

Pesquisadores demonstraram que uma folha de cálculo maliciosa pode forçar o LibreOffice e o Apache OpenOffice a executar código controlado por um atacante no momento em que o arquivo é aberto, sem mostrar a advertência de confiança que aparece antes de executar uma macro. O vetor explora a capacidade de Calc para definir faixas de dados ligadas a bases de dados externas (arquivos ODB) e a faculdade de carregar controladores JDBC em Java, de modo que a aplicação descarrega e arranca um JAR remoto dentro do seu próprio processo. O LibreOffice já lançou uma correção (seguida como CVE-2026-63277) em 5 de outubro; o Apache OpenOffice continua vulnerável em sua versão atual 4.1.16 e registra a falha como CVE-2026-59265, com um arranjo previsto para a 4.1.17.

Em termos técnicos, o ataque acorrente três funções legítimas de Calc. Primeiro, um "database range" pode ser configurado para se refrescar automaticamente de uma fonte externa; essa fonte pode ser um ficheiro ODB cuja localização é guardada na folha. Em segundo lugar, um ODB pode indicar que controlador de base de dados Java (JDBC) usar e onde reside o seu código, normalmente empacotado num ficheiro JAR. Terceiro, se o suporte Java estiver activo na instalação do LibreOffice/OpenOffice, a suíte download o JAR e arranca o controlador dentro do mesmo processo de aplicação. O problema de segurança não é uma função rota, mas a combinação dessas funções que resulta em execução de código sem a verificação de confiança aplicada às macros.

Calc do LibreOffice/OpenOffice permite execução de código remoto ao abrir folhas com ODB/JDBC
Imagem gerada com IA.

Os pesquisadores realizaram um teste de conceito no Windows e Linux; nesse PoC o "driver" malicioso abria a calculadora do sistema como demonstração inocua, mas a mesma cadeia pode executar qualquer código Java uma vez que o JAR se carrega. Em demonstrações públicas, os arquivos residiam localmente para facilitar a reprodução, mas os autores apontam que um ataque real colocaria o ODB e os JAR em servidores controlados pelo atacante para que a vítima os baixe ao abrir a folha.

Atos confirmados: O LibreOffice corrigiu a vulnerabilidade e recomenda atualizar as versões 26.2.5 ou 26.8.0; o Apache OpenOffice reconhece a falha e mantém todas as suas versões até 4.1.16 como afetadas, com uma solução prevista em 4.1.17. Os erros foram relatados pelas assinaturas de pesquisa citadas (V12 Security e Codean Labs) e a correção do LibreOffice foi implementada por um desenvolvedor de Collabora Produtividadeity. Não há, por agora, relatórios públicos verificados de que o exploit tenha sido usado em ataques reais.

Estimações e pontos ainda incertos: Não está claro quantos usuários mantêm o suporte Java ativado nestas suítes em ambientes de desktop ou que fração de implantação em empresas poderia ser vulnerável por configuração. Também não há provas públicas de campanhas em massa que estejam aproveitando este caminho; a disponibilidade de um PoC aumenta a probabilidade de exploits dirigidos, mas a transição de PoC para exploração real depende de fatores operacionais (por exemplo, que a vítima abra uma folha de cálculo não confiável e tenha Java habilitado).

Quem afeta isto? Principalmente usuários e organizações que usam o LibreOffice ou o Apache OpenOffice com o suporte Java ativado e que abrem folhas de cálculo provenientes de origens não verificadas. Os ambientes onde são aceites arquivos ODF/Ods de fornecedores externos, equipamentos de finanças, administração ou qualquer fluxo que processa folhas de cálculo recebidas por correio são especialmente relevantes, porque um ficheiro que à primeira vista é uma folha de cálculo pode conter a referência ODB que desencadeia a descarga e carga do JAR malicioso.

Consequências reais possíveis: execução remota de código no contexto do processo da suíte ofimática, o que pode resultar em roubo de dados locais, descarga de cargas adicionais, movimento lateral em redes internas ou estabelecimento de persistência se o atacante tiver privilégios suficientes. Uma vez que a execução ocorre no processo de usuário, as permissões disponíveis serão as do usuário que abriu o documento.

Medidas concretas a tomar pelo leitor agora mesmo:

1) Actualice se usar o LibreOffice. Instale as versões corrigidas indicadas pelo projeto (mencionadas pela própria fundação) ou a última versão estável disponível no site oficial: https://www.livreoffice.org. Essa é a defesa definitiva para instalações que não possam prescindir do suporte Java.

2) Se usar o Apache OpenOffice e não puder ainda atualizar, desactive Java. Abra as opções do programa e desligue o uso de um ambiente de execução Java (JRE). Isto impede que Calc baixe e arranque controladores JDBC externos e bloqueia este vetor de ataque. A configuração do Java está exposta na interface de opções de ambas as suítes; se não tiver a certeza, contacte a sua equipe de TI.

3) Não abra folhas de cálculo de origem desconhecida ou inesperada. Tente com especial cautela arquivos recebidos por e-mail, mesmo que sejam de contatos legítimos cujos sistemas poderiam ter sido comprometidos. Quando precisar de analisar um ficheiro suspeito, faça-o numa máquina isolada ou numa sandbox/VM sem acesso a credenciais corporativas.

4) Reduza a exposição por rede e por processo. Em ambientes corporativos, limite a capacidade da suíte ofimática para estabelecer conexões salientes mediante regras de firewall ou proxies, e considere políticas que impeçam que processos de escritório baixem código executável. Aplicações como o AppArmor ou o SELinux podem ajudar a restringir o binário do LibreOffice/OpenOffice pode carregar ou executar.

Calc do LibreOffice/OpenOffice permite execução de código remoto ao abrir folhas com ODB/JDBC
Imagem gerada com IA.

5) Para administradores: atualizar inventário, aplicar mitigações e monitorar. Identifique equipamentos com Java ativado no LibreOffice/OpenOffice e priorize atualizações ou desativação de Java. Agregue detecção de tráfego incomum a servidores que alojen ODB/JAR remotos e verifique os registros de endpoints por processos que abram conexões HTTP(S) após a abertura de documentos ofimáticos.

Para melhor compreender o componente JDBC que permite este abuso, consultar a documentação técnica do Oracle sobre o JDBC: https://docs.oracle.com/javase/8/docs/technotes/guides/jdbc/. Para informações oficiais e downloads das suites afetadas, use as páginas dos projetos: LibreOffice e Apache OpenOffice.

Em resumo: a vulnerabilidade não é uma falha de uma única função, mas o resultado da orquestração de mecanismos legítimos que, combinados, permitem executar código sem pedir a confirmação que se exige às macros. Actualizar o LibreOffice ou desativar o Java no OpenOffice, juntamente com boas práticas de gerenciamento de documentos e controles de rede, são as defesas mais eficazes até que o Apache publique sua correção. Manteremos a cobertura de acordo com os projetos publicam avisos e adesivos adicionais.

Cobertura

Relacionadas

Mas notícias do mesmo assunto.