Kaputte PDF-Dateien

Eine verblüffende Beobachtung. Nachtrag 3 (siehe ganz unten)

Ich habe mir vor ein paar Jahren mal – rudimentär und zusammengehackt, nur soweit sie ihren Zweck erfüllen soll – eine kleine Software geschrieben, die PDF-Dateien einlesen, verändern und modifizieren kann. Und dann nicht weiterentwickelt, weil sie erstens ihren Zweck erfüllt hatte, und es zweitens unter Ubuntu gepflegte Tools gibt (qpdf und pdftk), die die meisten Aufgaben, die ich benötige, erfüllen. Beispielsweise aus PDF-Dokumenten Seiten ausschneiden, oder mehrere PDF-Dokumente zu einem zusammenpappen.

Nun hab ich aber doch noch was anderes gebraucht und deshalb meine alten Routinen wieder ausgegraben. Ein altes Problem der Software tauchte auch gleich wieder – und noch verstärkt – auf. Nämlich das, daß die Software beim Einlesen von PDF-Dateien häufig mit Fehlermeldungen abbricht. Ich habe, wie es so meine Art ist (Security läßt grüßen), viele Abfragen auf Soll-Ist und Konformität drin, und werfe gleich Exceptions, wenn irgendwas nicht so ist, wie ich es da erwarte.

Nachdem mir die Software aber gar zu häufig mit irgendwelchen Exceptions ausstieg, dachte ich, daß ich da an diversen Stellen wohl ordentlichen Mist zusammenprogrammiert haben müßte, denn die normalen PDF-Reader können die Dateien problemlos anzeigen. Muß also an mir liegen, daß ich da irgendwas falsch gemacht haben muß. Also bin ich auf die Suche gegangen.

Das Ergebnis der Fehlersuche war aber, daß ich eigentlich nichts falsch gemacht, sondern mich genau an die PDF-Spezifikation gehalten habe. Eine verblüffend hohe Zahl von PDF-Dateien aus dem Internet tut das aber nicht. Es ist erstaunlich, wieviele Fehler man in diesen PDF-Dateien findet (muß wohl verdammt schwer sein, Software zu produzieren, die eine Datei nach einem vorgegebenen Format zu schreiben und mal reinzugucken, ob sie das wirklich tut). Zugegeben, die Semantik ist komplex und nicht immer so genau definiert, da kann man schon mal was falsch machen. Aber wenigstens die Datei-Syntax müßte doch stimmen. Was mir bisher so untergekommen ist:

• Unvollständige Daten. Einträge in den Dictionaries oder ganze Objekte fehlen einfach, sind aber referenziert.
• Fehlende Ref-Tables. Am Ende einer PDF-Datei findet man eine Tabelle mit den Offsets, wo in der Datei man die einzelnen Elemente findet. Damit die Software nicht die ganze Datei durchsuchen, sondern nur das lesen muß, was man gerade anzeigen will. (Deshalb werden PDFs immer von hinten gelesen, und deshalb können Browser auch einzelne Seiten aus PDFs anzeigen, ohne die ganze PDF-Datei zu holen.) Ich habe aber Dateien aus dem Internet, in denen diese Ref-Tabelle (samt der startxref-Angabe) einfach fehlt oder syntaktisch so vermurkst ist, daß man sie nicht finden und erkennen kann. Siehe dazu meinen Nachtrag von unten.
• Falsche startxref, als ergänzendes Problem dazu. Ganz an Ende der Datei steht, wo die eben beschriebene Ref-Tabelle zu finden ist. Manchmal zeigt diese Angabe aber an eine völlig falsche Stelle.

  (Nachtrag:) Das hängt sicherlich damit zusammen, daß ab PDF Version 1.5 sogenannte „Linearized PDFs” zulässig sind, bei denen die startxref-Angabe statt auf eine Referenz-Tabelle auch auf Dictionary zeigen kann, in dessen Stream die Referenzen stehen. Muß ich nochmal genauer nachlesen, wann diese Linearized PDFs zulässig sind, aber da scheint es einiges Durcheinander zu geben.

• Daten, die nicht da reingehören. Jahrelang habe ich gepredigt, Leute, verschickt an die Außenwelt keine Word-Dateien, weil Word nicht nur die ganze Editionshistorie (und weil Leute gerne andere Dokumente als Vorlage verwenden, nicht selten auch Informationen aus anderen Dokumenten mitrutschen) enthält, sondern (zumindest in früheren Versionen der Software) bekanntermaßen auch manchmal Speicherinhalte in das Dokument einlagert, die mit dem Dokument nichts zu tun haben und da nicht reingehören. Nehmt PDF, hab ich gepredigt.

  Ich hab nun aber auch Dateien gefunden, bei denen einfach hinter dem regulären Ende noch etliche zusätzliche Bytes mit Inhalten dranhingen, die mit dem PDF nichts zu tun haben. Stücke aus HTML-Seiten beispielsweise, wo man dann raten kann, daß das PDF von irgendeiner Software im Webserver dynamisch erzeugt und versehentlich zuviel Speicher rausgeschrieben wurde, in dem dann eben noch alte Inhalte hingen.

  Abgesehen davon, daß das natürlich zu einem syntaktisch fehlerhaften und eigentlich nicht mehr zu parsenden PDF-Dokument führt (weil man eben die Angaben am Dateiende nicht mehr findet, wenn noch Mist dahinterhängt), werden so natürlich auch Daten kompromittiert.

Da scheint eine Menge an schlechter Software im Umlauf zu sein.

Was mich allerdings verblüfft ist die Tatsache, daß die PDF-Reader unter Linux (und vermutlich auch die unter Windows) das Zeugs trotz der Fehler alles klaglos anzeigen. Die müssen einen ziemlichen Aufwand getrieben haben, um da die Brocken wieder zusammenflicken zu können. Respekt! (Vielleicht ist das aber gerade schlecht, weil so die Schreiberlinge nicht merken, daß sie gerade Murks produziert haben. Vielleicht wären die Dateien in Ordnung, wenn die PDF-Reader intolerant wären.)

Und das ist gar nicht so einfach. Natürlich habe ich auch versucht, einige Fehler zu workarounden.

Beispielsweise versuche ich, fehlende oder nicht brauchbare Referenztabellen dadurch zu ersetzen, daß ich die PDF-Dateien einfach linear von vorne nach hinten lese und die gefundenen Objekte selbst in eine Tabelle eintrage, also damit die Referenztabelle selbst erzeugt. Geht auch oft. Manchmal aber eben auch nicht. Denn PDF hat eine Besonderheit. PDF-Dateien enthalten Streams. Das sind Datenstücke aus beliebigen Binärdaten, sprich Bytefolgen, wie etwa Fonts, Bilder usw., die keiner syntaktischen Regel unterliegen, sondern einfach beliebige Bytefolgen sind. Sie sind an ein Dictionary angehängt, in dem steht, wie lange diese Bytefolgen sind. Wir haben also generell eine syntaktisch gut definierte PDF-Datei, in dem Bytefolgen vorkommen, die aus diesem Muster ausbrechen. Dazu weiß man, wie lange sie sind, daß also die nächsten n Byte nicht PDF-Syntax, sondern irgendwas sind und am Block gelesen oder übersprungen werden.

Nun kann in PDF aber jede Zahlenangabe auch durch eine Referenz auf ein anderes Objekt dargestellt sein. Was also zu der verblüffenden (und gar nicht so seltenen) Situation führt, daß an einer Stelle ein Stream aus beliebigen Daten kommt, und erst später in der Datei irgendwo anders steht, wie lange der Stream ist, wieviele Bytes also dazugehören. Man kann das also nicht systematisch von vorne nach hinten lesen, weil man ja nicht weiß, wo wieder normales PDF anfängt, um dann das Objekt mit der gesuchten Längenangabe zu finden. Daß es trotzdem geht, liegt allein an der oben erwähnten Referenztabelle. Durch die weiß man auch so, wo das Objekt mit der Zahlenangabe steht, kann also an diese Stelle springen, die Länge des Streams herauslesen, und weiß dann, wieviele Bytes zum Stream gehören. Umständlich, funktioniert aber.

Wenn aber diese Referenztabelle (wie oben beschrieben) fehlerhafterweise fehlt, dann hat man ein Problem. Da man nicht weiß, wie lange der Stream ist, weiß man nicht, wo man mit dem Parsen wieder einsetzen kann um die Längenangabe zu finden. Eigentlich ist die Datei dann syntaktisch unlesbar kaputt. Man könnte zwar (und vermutlich machen das die Reader auch) heuristisch raten, indem man einfach in der Datei nach dem sucht, was normalerweise an Ende eines solchen Streams steht (endobj usw.), und damit mit hoher Wahrscheinlichkeit die richtige Stelle und damit auch die Länge des Streams zu finden, aber so richtig gut ist das nicht. Denn niemand verbietet etwa einen JPEG-Bild, gerade solche Byte-Folgen zu enthalten. Oder prinzipiell könnte ein Stream auch eine andere PDF-Datei enthalten, in der sich solche Syntax-Elemente finden. Es ist also heuristische Rate-Kunst. Meistens geht’s zwar, aber zuverlässig ist es nicht.

Umso bemerkenswerter ist es, daß die PDF-Reader den Mist trotzdem ordentlich anzeigen können. Da muß einiges an Rate-Intelligenz drin stecken.

Wie aber schon angesprochen, führt erst diese Tolereanz der Reader zu der hohen Verbreitung von kaputter PDFs. Könnte man sie nicht lesen, würden sie sich nicht verbreiten, und würde der Autor sie meist auch nicht freigeben. Würden sich Kunden über die PDF-Erzeugungssoftware beschweren.

So aber ist da draußen eine unglaubliche Menge an fehlerhafter Software und murksigen PDFs unterwegs, die jeden Autor eines PDF-Readers effektiv zwingt, sich der Toleranz anderer Browser anzuschließen, um keine Kunden zu verlieren. Denn der Kunde freut sich ja nicht darüber, daß sein PDF-Reader so pingelig ist, daß er alles ablehnt, was sich nicht an den Standard hält, sondern freut sich darüber, daß der andere Reader alles anzeigt. Weil ihm das besser vorkommt. Und so schraubt sich die Spirale der Fehler immer höher.

Es ist längst bekannt, daß PDFs aus dem ehemalig konzeptionell sicheren Dateiformat (auch wegen der Idiotie von Adobe, da JavaScript und so’n Mist reinzuschrauben) zu einer generellen Sicherheitsbedrohung und einem Haupteinfalltor für Angriffe geworden sind.

Vermutlich wären sie das weniger, wenn die Reader die Syntax strikt prüfen und alles ablehnen würden, was fehlerhaft ist. Vermutlich ist ein auf Raten und Toleranz gestrickter Reader viel angriffsanfälliger als ein knallhart strenger. Aber der Kunde bevorzugt ja Browser, die das Dokument und nicht die Fehlermeldung anzeigen.

Nachtrag 2: Ein Teil der beobachteten Fehler war in Wirklichkeit ein Fehler von mir, denn ich hatte mich bei der Dateistruktur an PDF 1.1 bis 1.4 orientiert und war irrtümlich davon ausgegangen, daß die an der Struktur an sich nichts geändert haben bzw. rückwärtskompatibel geblieben sind. Sind sie aber nicht.

Ab PDF 1.5 werden die Objekt-Referenzen nicht mehr primär in der beschreibenen XREF-Tabelle angegeben, sondern im komprimierten Stream eines Dictionary-Objects binär codiert und mit variablen Feldbreiten (abgefahren…) abgelegt. Dazu kommen etliche Schikanen und Sonderfälle, wie etwa das Index-Feld, das das ganze nochmal in Subsections unterteilen kann, aber nicht muß. Die Komplikation, daß Objekte nunmehr auch selbst wieder als komprimierter Stream in anderen Objekten abgelegt werden kann. Und weil das alles so schön inkompatibel zum alten Standard ist, obendrein auch noch die Möglichkeit des „hybrid reference file”, man kann also zur Rückwärtskompatibilität auch in einem PDF 1.5 zusätzlich noch die alte xref-Tabelle angeben, damit es auch Browser lesen können, die eigentlich kein PDF 1.5 können.

Um diesen ganzen Kram korrekt zu dekodieren schreibt man sich die Finger wund. Unglaublich, was man da alles an Sonderfällen berücksichtigen und an möglichen Falschangaben abfangen muß. Wenn man das dann beispielsweise noch in einer Sprache schreibt, die keine Array-Grenzen überwacht oder die keine Unsigned Integer kennt (einem ein Angreifer also noch negative Zahlen usw. unterjubeln kann) dann ist das kaum möglich, ein wirklich wasserdichtes Programm zu schreiben. Die haben PDF da einfach zu komplex gemacht.

Und momentan kämpfe ich gerade damit, daß der Aufbau dieser Indextabellen in einer PDF-Datei, die ich hier habe, partout nicht zu dem passen will, was im PDF-Manual beschrieben ist.

Da merkt man so richtig, wie ein ehedem sauberes und stabiles Format so ungefähr ab 1.5 plötzlich verkompliziert wurde. Als ob es jemand geradezu erschweren wollte.

Nachtrag 3 Ich krieg gerade die Motten.

Der Grund, warum die Index-Daten nicht so aussehen, wie ich sie erwarten würde, liegt am Kompressionsverfahren. PDF verwendet zur Kompression u.a. FlateDecode, das Verfahren von zip und unzip. Da ich die Software aktuell unter Ruby schreibe, habe ich da bisher immer die zlib Library verwendet. Die hat das bisher auch getan, was sie sollte (zumindest soweit ich es bemerkt habe). Nun ist mir ein Fehler aufgefallen.

Denn wenn ich mit zlib dekomprimiere, haben die unkomprimierten Daten eine andere Länge als sie haben sollten (und auch eben teils andere Daten).

Der Grund ist, daß PDF den Kompressionsalgorithmus parametrisiert und sog. Predictoren bzw. Filter verwendet. Und die PDFs, an denen ich gerade nage, verwenden Parameter und Filter für PNG-Graphiken, um die Index-Daten im PDF-Dokument zu komprimieren. Das heißt, man kann sie nur dann korrekt dekomprimieren, wenn man die richtigen Filter angibt. Und die Ruby-zlib-Schnittstelle erlaubt sowas nicht. Liebe Zeit…