LibreOffice y OpenOffice: fallos que ejecutan código sin macros

El riesgo ya no está en la macro que vesDurante años hemos asociado el peligro de los documentos ofimáticos a las macros: ese aviso amarillo que apare...

El riesgo ya no está en la macro que ves

Durante años hemos asociado el peligro de los documentos ofimáticos a las macros: ese aviso amarillo que aparece al abrir un fichero y que muchos usuarios aprenden a ignorar. El problema es que la nueva generación de fallos no necesita esa ventana de advertencia. Basta con abrir una hoja de cálculo manipulada para que se ejecute código en el equipo, sin botones sospechosos ni diálogos intermedios. Es un cambio de reglas que afecta tanto a estaciones de trabajo como a servidores que procesan documentos de forma automática.

En esta ocasión, las vulnerabilidades afectan a LibreOffice Calc y a Apache OpenOffice, y ambas explotan la integración con Java y la manera en que estas suites cargan componentes al abrir documentos no fiables. La lección es clara: si tu organización intercambia hojas de cálculo con conexiones a fuentes de datos externas, tienes un punto débil que conviene revisar hoy mismo.

Qué falla exactamente en LibreOffice Calc

El fallo de LibreOffice Calc permite que un documento fuerce la carga de un controlador Java para bases de datos desde una ubicación remota. La clave técnica está en el class path: si una de sus entradas apunta a un recurso fuera del equipo, el documento puede inducir a la aplicación a resolver clases desde un origen controlado por el atacante. En la práctica, es como si el fichero trajera una pieza de recambio que en realidad viene de fuera de casa.

La corrección endurece ese comportamiento y obliga a que cada entrada del class path sea una URL de tipo file, lo que bloquea la carga de clases desde ubicaciones remotas. La recomendación es directa: actualizar a las versiones corregidas cuanto antes. Ese salto reduce el riesgo asociado a enlaces de datos externos y a conectores JDBC en Calc, un punto delicado en entornos donde se intercambian hojas con conexiones a orígenes de datos corporativos.

OpenOffice: mitigación temporal mientras llega el parche

El caso de Apache OpenOffice es más incómodo. La vulnerabilidad afecta a la versión 4.1.16 y anteriores y permite ejecución de código local o remoto al abrir un documento no confiable que aprovecha la integración con Java. La corrección estable aún no está disponible, así que toca gestionar el riesgo con medidas provisionales.

La más eficaz consiste en desactivar la integración con Java si no resulta imprescindible. También conviene limitar el uso de Java en suites ofimáticas en general en aquellos puestos que abren adjuntos con frecuencia, reforzar las políticas internas para no abrir ficheros de procedencia dudosa y recurrir al aislamiento cuando sea posible. En escritorio, el enfoque de mínimos privilegios marca la diferencia: si el código llega a ejecutarse, el alcance se queda dentro del perímetro de permisos del usuario.

Más allá del parche: repensar la superficie de ataque

Este episodio deja una lectura estratégica para empresas de hosting, pymes con servidores propios y administradores de sistemas en Cataluña y el resto de España. Mantener OpenOffice como pieza crítica sin un ciclo de parches ágil obliga a plantearse una sustitución o migración. Cuando el ataque entra por el documento que alguien abre «solo para mirar un dato», cada semana sin actualización cuenta.

Algunas medidas que puedes aplicar desde ya:

Actualizar LibreOffice a las versiones corregidas en todos los equipos y servidores donde se procesen documentos.
Desactivar Java en OpenOffice si no es necesario para la operativa diaria.
Aplicar el principio de mínimo privilegio a las cuentas que abren adjuntos.
Aislar la ejecución de documentos ofimáticos en entornos controlados o contenedores.
Revisar los flujos internos que automatizan la apertura de hojas de cálculo, porque ahí el riesgo se multiplica sin intervención humana.

La capa que falta: proteger la infraestructura que procesa documentos

Actualizar el software ofimático es imprescindible, pero no suficiente. Los servidores que reciben, convierten o almacenan documentos son un objetivo habitual: un atacante que consigue ejecutar código en una máquina puede intentar después moverse lateralmente, abrir conexiones salientes o dejar puertas traseras. Ahí es donde una estrategia de seguridad de servidores marca la diferencia.

En ALMC trabajamos con Abuse Shield, un servicio que centraliza la protección de tus servidores: bloqueo automático de IPs maliciosas, fail2ban gestionado en múltiples máquinas y un feed de reputación compartido entre todos tus servidores. Si una IP intenta explotar una vulnerabilidad en una máquina, el resto de la flota lo sabe al instante y puede reaccionar antes de que el ataque se propague. Es la diferencia entre parchear cada equipo por separado y tener una defensa coordinada.

Para una empresa de hosting en Lleida, Barcelona, Tarragona o Girona, esto se traduce en menos incidentes repetidos, menos tiempo dedicado a tareas manuales de bloqueo y una reputación de IP más limpia, algo crítico cuando tus clientes dependen del correo y de los servicios web. En ciberseguridad, la visibilidad compartida vale tanto como el parche más rápido.

Conclusión: parchea, aísla y coordina

Los fallos de LibreOffice y OpenOffice nos recuerdan que la ofimática sigue siendo una vía de entrada real, y que la ausencia de avisos de macros no significa ausencia de riesgo. Actualiza, desactiva Java cuando no sea necesario, aplica mínimos privilegios y acompaña todo ello con una capa de protección perimetral que abarque todos tus servidores. La seguridad no es un parche aislado: es una rutina que se mantiene en el tiempo.

Relacionado

¿Tus servidores bajo ataque constante?

Centraliza fail2ban y la reputación de IPs en todos tus servidores. Descubre Abuse Shield de ALMC. Contáctanos para una demo personalizada.

Resultados sin salir de la página.