{"id":101354,"date":"2021-09-21T10:22:45","date_gmt":"2021-09-21T08:22:45","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/uyazvimost-v-openoffice-pozvolyayushhaya-vypolnit-kod-pri-otkrytii-fajla"},"modified":"2021-09-21T10:22:45","modified_gmt":"2021-09-21T08:22:45","slug":"uyazvimost-v-openoffice-pozvolyayushhaya-vypolnit-kod-pri-otkrytii-fajla","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/news\/uyazvimost-v-openoffice-pozvolyayushhaya-vypolnit-kod-pri-otkrytii-fajla","title":{"rendered":"Una vulnerabilidad en OpenOffice permite ejecutar c\u00f3digo al abrir un archivo","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Se ha detectado una vulnerabilidad en el paquete de oficina Apache OpenOffice (CVE-2021-33035), que permite la ejecuci\u00f3n de c\u00f3digo al abrir un archivo especialmente dise\u00f1ado en formato DBF. El investigador que descubri\u00f3 el problema advirti\u00f3 sobre la creaci\u00f3n de un exploit funcional para la plataforma Windows. La correcci\u00f3n de la vulnerabilidad est\u00e1 disponible por ahora solo en forma de parche en el repositorio del proyecto, que ha sido incluido en las compilaciones de prueba de OpenOffice 4.1.11. Las actualizaciones para la rama estable a\u00fan no se han creado. <\/p>\n
El problema fue causado por el hecho de que al asignar memoria, OpenOffice confiaba en los valores fieldLength y fieldType en el encabezado de los archivos DBF, sin verificar la correspondencia con el tipo de datos real en los campos. Para llevar a cabo un ataque, se puede especificar en el valor fieldType el tipo INTEGER, pero colocar datos de mayor tama\u00f1o y especificar un valor fieldLength que no coincide con el tama\u00f1o de los datos del tipo INTEGER, lo que provocar\u00e1 que la parte final de los datos del campo se escriba m\u00e1s all\u00e1 del b\u00fafer asignado. Como resultado de un desbordamiento de b\u00fafer controlado, el investigador pudo sobrescribir el puntero de retorno de la funci\u00f3n y, mediante t\u00e9cnicas de programaci\u00f3n orientada a retorno (ROP - Return-Oriented Programming), ejecutar su propio c\u00f3digo. <\/p>\n
Al utilizar la t\u00e9cnica ROP, el atacante no intenta colocar su c\u00f3digo en la memoria, sino que opera con fragmentos de instrucciones de m\u00e1quina ya existentes en las bibliotecas cargadas, que terminan con una instrucci\u00f3n de retorno (por lo general, son finales de funciones de biblioteca). La explotaci\u00f3n se reduce a construir una cadena de llamadas a bloques similares (\"gadgets\") para obtener la funcionalidad deseada. Como gadgets en la explotaci\u00f3n para OpenOffice se utiliz\u00f3 c\u00f3digo de la biblioteca libxml2, que a diferencia de OpenOffice, se compil\u00f3 sin mecanismos de protecci\u00f3n DEP (Prevenci\u00f3n de Ejecuci\u00f3n de Datos) y ASLR (Aleatorizaci\u00f3n de Dise\u00f1o de Espacios de Direcciones). <\/p>\n
Los desarrolladores de OpenOffice fueron notificados del problema el 4 de mayo, y se program\u00f3 una divulgaci\u00f3n p\u00fablica de la vulnerabilidad para el 30 de agosto. Dado que para la fecha prevista, la actualizaci\u00f3n de la rama estable no se form\u00f3, el investigador traslad\u00f3 la divulgaci\u00f3n de los detalles al 18 de septiembre, pero los desarrolladores de OpenOffice no lograron formular el lanzamiento 4.1.11 para esa fecha. Es notable que, en el mismo estudio, se identific\u00f3 una vulnerabilidad similar en el c\u00f3digo de soporte del formato DBF en Microsoft Office Access (CVE-2021-38646), cuyos detalles se revelar\u00e1n m\u00e1s adelante. No se encontraron problemas en LibreOffice. \n Fuente: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"