{"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\/de\/blog\/novosti-interneta\/uyazvimost-v-openoffice-pozvolyayushhaya-vypolnit-kod-pri-otkrytii-fajla","title":{"rendered":"Sicherheitsanf\u00e4lligkeit in OpenOffice, die die Ausf\u00fchrung von Code beim \u00d6ffnen einer Datei erm\u00f6glicht","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Im B\u00fcro-Paket Apache OpenOffice wurde eine Sicherheitsanf\u00e4lligkeit (CVE-2021-33035) festgestellt, die die Ausf\u00fchrung von Code beim \u00d6ffnen einer speziell gestalteten Datei im DBF-Format erm\u00f6glicht. Der entdeckende Forscher warnte vor der Erstellung eines funktionierenden Exploits f\u00fcr die Windows-Plattform. Ein Fix f\u00fcr die Schwachstelle ist derzeit nur als Patch im Repository des Projekts verf\u00fcgbar, das Teil der Testversionen von OpenOffice 4.1.11 ist. Updates f\u00fcr den stabilen Branch wurden bislang nicht bereitgestellt. <\/p>\n
Das Problem entsteht, weil OpenOffice beim Zuweisen von Speicher auf die Werte von fieldLength und fieldType im Header von DBF-Dateien vertraute, ohne die \u00dcbereinstimmung des tats\u00e4chlichen Datentyps in den Feldern zu \u00fcberpr\u00fcfen. Ein Angreifer kann den fieldType auf INTEGER setzen, jedoch gr\u00f6\u00dfere Daten angeben und einen fieldLength-Wert verwenden, der nicht der Gr\u00f6\u00dfe der Daten des Typs INTEGER entspricht, was dazu f\u00fchrt, dass das Datenende aus dem Feld \u00fcber den zugewiesenen Puffer hinaus geschrieben wird. Infolge dieser kontrollierten Puffer\u00fcberlauf-Anf\u00e4lligkeit gelang es dem Forscher, den R\u00fcckgabepointer aus der Funktion umzupolen und durch Techniken der R\u00fcckkehrorientierten Programmierung (ROP - Return-Oriented Programming) die Ausf\u00fchrung seines Codes zu erm\u00f6glichen. <\/p>\n
Bei der Verwendung der ROP-Technik versucht der Angreifer nicht, seinen eigenen Code im Speicher abzulegen, sondern greift auf bereits vorhandene St\u00fccke von Maschinenanweisungen in den geladenen Bibliotheken zur\u00fcck, die mit einer R\u00fcckkehranweisung enden (in der Regel sind dies die Enden von Bibliotheksfunktionen). Die Funktion des Exploits besteht darin, eine Kette von Aufrufen solcher Bl\u00f6cke (sogenannten \u201eGadgets\u201c) zu erstellen, um die ben\u00f6tigte Funktionalit\u00e4t zu erreichen. F\u00fcr den Exploit in OpenOffice wurde Code aus der in OpenOffice verwendeten Bibliothek libxml2 verwendet, die im Gegensatz zu OpenOffice ohne Schutzmechanismen wie DEP (Data Execution Prevention) und ASLR (Address Space Layout Randomization) kompiliert wurde. <\/p>\n
Die Entwickler von OpenOffice wurden am 4. Mai \u00fcber das Problem informiert, und die \u00f6ffentliche Bekanntgabe der Sicherheitsanf\u00e4lligkeit war f\u00fcr den 30. August geplant. Da bis zu diesem Termin kein Update des stabilen Zweigs bereitgestellt wurde, verschob der Forscher die Offenlegung der Details auf den 18. September. Allerdings konnten die Entwickler von OpenOffice bis zu diesem Zeitpunkt kein Release 4.1.11 bereitstellen. Bemerkenswert ist, dass im Zuge derselben Untersuchung eine \u00e4hnliche Sicherheitsanf\u00e4lligkeit im Code zur Unterst\u00fctzung des DBF-Formats in Microsoft Office Access (CVE-2021\u201338646) festgestellt wurde, deren Einzelheiten sp\u00e4ter ver\u00f6ffentlicht werden. In LibreOffice wurden keine Probleme gefunden. \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"