Das RTF-Format unterstützt seit Winword 95 auch sog. "eingebettete OLE-Objekte" (OLE = Object Linking and Embedding). Wird eine RTF-Datei mit einem solchen OLE-Objekt in einem Programm wie Winword oder Wordpad geladen, und klickt der Benutzer auf das Symbol des OLE-Objekts in der Datei, so startet Winword/Wordpad automatisch das hinterlegte "Ursprungsprogramm" mit den angegebenen "Daten".
Leider erfolgt dabei weder eine Prüfung des angeblichen "Ursprungsprogramms" noch der "Daten", mit denen dieses Programm aufgerufen wird. Mit geeignet gestalteten RTF-Dateien läßt sich somit jeder beliebige Befehl des Betriebssystems hinter dem OLE-Symbol verstecken.
Ein Beispiel für eine solche RTF-Datei zeigt der bulgarische Programmierer Georgi Guninski unter der Adresse http://www.guninski.com/wordpad-desc.html, wo eine harmlos aussehende RTF-Datei beim Mausklick auf eine Grafik den Befehl "AUTOEXEC.BAT" ausführt. (Dieses konkrete Beispiel ist natürlich unschädlich - der Befehl läßt sich jedoch leicht durch etwas "Unangenehmeres" wie z. B. "deltree c:\ /y" ersetzen!)
Das geschilderte "Mausklick-Risiko" entsteht durch Passagen in RTF-Dateien, die folgendermaßen aufgebaut sind:
{\object...{\*\objdata...}{\result...}}
Hinter \object stehen dabei diverse Objekteigenschaften, hinter \*\objdata die dynamischen Objektdaten (= der potentiell gefährliche Programmaufruf) und hinter \result das bisherige "Ergebnis" des Aufrufs (= die angezeigte Grafik o. ä.).
Ob ein OLE-Objekt harmlos oder gefährlich ist, hängt somit von dem Teil zwischen \*\objdata und der nächsten schließenden Klammer } ab. Dort steht, was bei einem Doppelklick auf das Objekt passieren soll - allerdings nicht in Klarschrift, sondern als hexadezimal kodiertes Ergebnis der sog. "OLESaveToStream"-Funktion. (Man kann daher einer RTF-Datei mit OLE-Objekten nicht ohne weiteres ansehen, ob die dynamischen Objektdaten harmlos oder gefährlich sind.)
Ab MS-Office 2000 enthält Winword laut Microsoft einen Schutz gegen die von Georgi Guninski aufgezeigte Gefahr. Wer das Originalbeispiel von Guninski in Winword 2000 lädt und dort auf die Grafik klickt, erhält nun eine Warnmeldung:
"Sie versuchen, ein eingebettetes Objekt zu aktivieren, das möglicherweise Viren enthalten oder Ihren Computer beschädigen könnte. ..."
Bei näherem Testen stellt sich jedoch heraus, daß Winword 2000 lediglich prüft, ob das aufgerufene "Ursprungsprogramm" aus der MS-Office-Familie stammt oder nicht. Bei "Fremdprogrammen" erscheint die obige Meldung, bei Office-Mitgliedern unterbleibt sie. Eine Analyse der eigentlichen Objektdaten findet nicht statt.
Ein solcher "Schutz" ist aber praktisch wirkungslos. Denn die von Guninski aufgezeigten Schadensmöglichkeiten lassen sich genausogut durch OLE-Aufrufe von Office-Modulen und die Nutzung der dort vorfügbaren Programmiersprache "Visual Basic for Applications" bewirken. Jeder gute OLE-Programmierer sollte in der Lage sein, das Guninski-Beispiel so abzuändern, daß es auch mit Office 2000 ohne jede Warnmeldung "zuschlägt".
Da OLE-Aufrufe wiederum die Automatisierungssprachen der jeweils aufgerufenen Programme nutzen können, ist eine 100%ige Analyse der dynamischen Objektdaten in OLE-Objekten leider nicht durchführbar. Ein zuverlässiger Schutz kann daher nur durch "Herausschneiden" aller dynamischen Objektdaten aus einer fremden RTF-Datei erzielt werden.
Aus einer Passage wie
{\object...{\*\objdata...}{\result...}}
ist daher alles bis auf den statischen Ergebnisteil (der in der obigen Zeile durch die 3 Punkte zwischen \result und der schließenden Klammer } angedeutet wird) zu entfernen. Dann bleiben Grafiken, Tabellen u. ä. aus OLE-Objekten erhalten, und lediglich die dynamische Änderungsmöglichkeit über Fremdprogramme entfällt.
Im einfachsten Fall könnte diese "Säuberungsaktion" durch eine reine Textersetzung erfolgen. Im allgemeinen Fall ist diese Vorgehensweise jedoch nicht zuverlässig, weil RTF-Dateien z. B. auch Binäranteile enthalten dürfen, die bei einer reinen Textersetzung zerstört werden können.
Ein Säuberungsprogramm, das mit allen RTF-Dateien zurechtkommen soll, darf sich daher nicht einfach an Zeichenfolgen orientieren, sondern muß anhand einer Analyse der formalen Syntax der RTF-Datei entscheiden, welche Teile zu entfernen sind.
[Zurück zu "Sicheres Austauschformat für elektronische Dokumente"]