Hace algunos dias se dio a conocer una vulnerabilidad que fue identificada en la suite ofimática Apache OpenOffice, este fallo catalogado bajo CVE-2021-33035 permite la ejecución de código al abrir un archivo especialmente diseñado en formato DBF.

El problema se debe a que OpenOffice se basa en los valores fieldLength y fieldType en el encabezado de los archivos DBF para asignar memoria sin verificar el tipo de datos real en los campos.

Sobre la vulnerabilidad

Para realizar un ataque, puede especificar el tipo INTEGER en el valor fieldType, pero colocar datos más grandes y especificar el valor fieldLength que no se corresponde con el tamaño de los datos INTEGER, lo que conducirá al hecho de que los datos cola del campo se escribirá fuera del búfer asignado.

Como resultado de un desbordamiento de búfer controlado, el investigador pudo redefinir el puntero de retorno de la función y utilizando técnicas de Programación Orientada al Retorno (ROP), lograr la ejecución de su código.

Un consejo que recibí al principio del viaje de investigación de vulnerabilidades fue centrarme en un formato de archivo, no en una pieza de software específica. Hay dos ventajas principales de este enfoque. En primer lugar, como principiante, carecía de la experiencia para identificar rápidamente vectores de ataque únicos en aplicaciones individuales, mientras que el análisis del formato de archivo tiende a ser un punto de entrada común entre muchas aplicaciones. 

Además, los formatos de archivo comunes están bien documentados mediante Solicitudes de comentarios (RFC) o código de fuente abierta, lo que reduce la cantidad de esfuerzo necesario para realizar ingeniería inversa en el formato.

Cuando se usa la técnica ROP, el atacante no intenta colocar su código en la memoria, sino que opera sobre las partes de las instrucciones de la máquina que ya están disponibles en las bibliotecas cargadas, terminando con una instrucción de retorno de control (como regla, estos son el final de la biblioteca funciones).

El trabajo del exploit se reduce a construir una cadena de llamadas a bloques similares («gadgets») para obtener la funcionalidad requerida.

Como gadgets en el exploit para OpenOffice, se menciona que se usó el código de la biblioteca libxml2 utilizada en OpenOffice, que, a diferencia de OpenOffice, resultó estar ensamblado sin mecanismos de protección DEP (Prevención de ejecución de datos) y ASLR (Address Space Layout Randomization).

Los desarrolladores de OpenOffice fueron notificados sobre el problema el 4 de mayo, después de lo cual se programó una divulgación pública de la vulnerabilidad para el 30 de agosto.

Dado que la rama estable no se actualizó en la fecha prevista, el investigador pospuso la divulgación de detalles hasta el 18 de septiembre, pero los desarrolladores de OpenOffice no tuvieron tiempo de formar la versión 4.1.11 en ese momento. Cabe destacar que en el transcurso del mismo estudio, se reveló una vulnerabilidad similar en el código para soportar el formato DBF en Microsoft Office Access (CVE-2021-38646), cuyos detalles se darán a conocer más adelante. No se encontraron problemas en LibreOffice.

Fue relativamente sencillo descubrir la documentación del formato de archivo para dBase; Wikipedia tiene una descripción simple de la versión 5 del formato y dBase LLC también proporciona una especificación actualizada . La Biblioteca del Congreso enumera un increíble catálogo de formatos de archivo, incluido DBF . Las diversas versiones y extensiones del formato DBF brindan amplias oportunidades para que los programadores introduzcan vulnerabilidades de análisis.

El formato DBF consta de dos secciones principales: el encabezado y el cuerpo. El encabezado incluye un prefijo que describe la versión de la base de datos de dBase, la última marca de tiempo de actualización y otros metadatos. Más importante aún, especifica la longitud de cada registro en la base de datos, la longitud de la estructura del encabezado, el número de registros y los campos de datos en un registro.

El investigador que identificó el problema advirtió sobre la creación de un exploit funcional para la plataforma Windows. La solución para la vulnerabilidad solo está disponible en forma de parche en el repositorio del proyecto, que se incluyó en las compilaciones de prueba de OpenOffice 4.1.11.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar la nota original en el siguiente enlace.