Minimalgebot für Datenformate - offener Standard sein reicht nicht

[Volker Grabsch]

Matthias Kirschner schrieb:
> Anlässlich des am Mittwoch stattfindenden Document Freedom Day
> <http://documentfreedom.org> veröffentlicht die FSFE einen Artikel vom
> Mitgründer der FSFE Bernhard Reiter. Es geht darum, was ein gutes
> Datenformat ausmacht, argumentiert, dass Offene Standards wichtig sind,
> aber das nicht ausreicht.  Seine Kernfrage bei Datenformaten ist: "Geht
> das einfacher?"
> 
> http://fsfe.org/projects/os/minimalisticstandards.html

Der Text gefällt mir ganz gut. Folgender Abschnitt ist
allerdings sehr missverständlich geschrieben:

| Wer Computer verstehen möchte, dem wird erklärt, dass es zwei
| verschiedene Dinge gibt: Daten und Programme. Während die Daten
| nur verarbeitet werden, enthalten die Programme Befehle für den
| Computer.

Soweit okay. Spätestens hier hätte ich jedoch ein
großes "Aber" erwartet. Denn gerade bei Computern
ist der Übergang zwischen Daten und Programmcode
fließend. Eines der Grundkonzepte von LISP, einer
uralten und immer noch benutzte Programmiersprache,
lautet sogar: Code is Data, Data is Code.

| Der Unterschied wird deutlich anhand eines Zettels auf
| dem steht: Spring von der Brücke! Diesen Zettel und den Satz
| kann ich problemlos lesen, aufschreiben und weitergeben - also
| verarbeiten. Sollte ich ihn als Befehl auffassen und aufführen,
| dann falle ich leicht auf die Nase.

Dieses Beispiel veranschaulicht das genaue Gegenteil:
Dass nämlich ein und der selbe Zettel verschiedenes
auslösen kann, je nach dem, wer ihn in die Hand bekommt.

| Das ist bei Rechnern genauso. Dateiformate wie ODF, Doc und
| PDF können neben Daten auch Anweisungen für automatische
| Bearbeitung ("Makros") oder interaktive Elemente (Javascript)
| enthalten.

Genau genommen ist aber schon jeder einzelne Text-Buchstabe
ein Befehl. Nämlich der Befehl, diesen Buchstaben an der
entsprechenden Position anzuzeigen.

| Das macht jede Datei zu einer potentiellen Anwendung mit
| Befehlen für meinen Computer.

Hier wird suggeriert, die Entstehung von Makros wäre
der Grund für die Doppelbedeutung von Daten und Code.
Das ist aber schlicht falsch!

Die Dualität von Code und Daten existiert immer, in
jedem informationsverarbeitenden System!

Sie wird durch Makros lediglich besonders verschärft.

| Klar, dass Angreifer das ausnutzen, wie bei den Makro-Viren. 

Und dieser letzte Satz sind das eigentliche Problem,
da er zusammen mit dem vorherigen Satz suggeriert,
Makro-Erweiterungen seien die Ursache für Computer-
Schädlinge.

Klar, unsichere Makro- und JavaScript-Interpreter haben
die Lage verschlimmert. Aber nur insofern, als dass ein
Angreifer nun platformübergreifend Angriffe durchführen
konnte. Vorher waren die Angriffe fast immer auf bestimmte
Hardware, Betriebssysteme, und -Versionen beschränkt.

Aber letztendlich löst jedes Dokument und jeder eingehende
Datenstrom im Computer Aktionen aus. Die Frage ist nur,
was er sich befehlen lässt und was nicht. Die Sicherheits-
lücke besteht darin, dass er sich mehr befehlen lässt als
beabsichtigt.

Oder besser gesagt: mehr als vom Anwender gewünscht.


Zum Schluss noch einige Beispiele, um die Unschärfe
zwischen Code und Daten weiter zu verdeutlichen:

1) Ich benutze ein E-Mail-Programm, das sich vom Absender
_nicht_ vorschreiben lässt, in welcher Schriftgröße mir
sein Text angezeigt wird. Alle E-Mails lese ich
in der gleichen Größe und Farbe. Andere E-Mail-Programme
lassen sich solche Sachen vom Absender vorschreiben, das
geht mir zu weit. -- des gleiche Prinzip, obwohl das überhaupt
nichts mit versendetem Programmcode oder Makros zu tun hat.

2) Ein Fehler in einer Grafik-Library (Ich glaube, es
war libjpeg) führte dazu, dass beim Anzeigen spezieller
Grafikdateien noch ganz andere Dinge passieren konnten.
Und das, obwohl Rastergrafiken (im Gegensatz zu Vektorgrafiken)
nun wirklich nichts enthalten, was man auch nur ansatzweise
als Programmcode bezeichnen würde. Dennoch ließ sich die
Bibliothek dazu bringen, Maschinencode auszuführen, der
im Datenstrom des Bildes "mitgeliefert" wurde und eigentlich
höchstens ein Rauschen in der angezeigten Grafik sein dürfte.

3) Das senden eines der kleinsten Daten-Pakete, die
im Internet herum fliegen (PING-Pakete) konnten alte
Windows-Versionen einfrieren lassen, wenn sie in Massen
über das Netzwerk gesendet wurde. Nicht einmal der Mauspfeil
ließ sich bewegen. Sobald der Datenstrom aufhörte, war der
Rechner wieder bedienbar. Man konnte also einen Computer
ferngesteuert anhalten, und auch wieder weiterarbeiten
lassen, ohne dass irgendwas im Spiel war, das auch nur
ansatzweise etwas mit Programmcode zu tun hatte.


Gruß
Volker

-- 
Volker Grabsch
---<<(())>>---