Hadmut Danisch

Ansichten eines Informatikers

Kaputte PDF-Dateien

Hadmut
21.7.2011 12:13

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…

18 Kommentare (RSS-Feed)

Sebastian
21.7.2011 12:57
Kommentarlink

Don’t blame the victim!

Man kann dem normalen User nicht vorwerfen, dass er funktionierende Software bevorzugt.

Bruce Schneier hat einen hervorragenden Artikel zu dem Thema verfasst:
http://www.schneier.com/blog/archives/2009/03/it_security_bla.html


Hadmut
21.7.2011 13:02
Kommentarlink

Ich hab’s ihm ja nicht vorgeworfen, sondern den Software-Autoren.


kalle
21.7.2011 13:05
Kommentarlink

Also völlig klaglos lesen die Unixtools solche Dateien auch nicht ein. evince haut bei mir immer die Konsole voll, diverse Konverter geben Warnungen aus,…

Imo kann pdf inzwischen zu viel. Dass die Reader ständig Sicherheitslücken haben ist kein Wunder, wie soll man solchen mist auch vernünftig parsen. Hält man sich streng an den Standard sind 90% nicht lesbar, ist man zu lasch in der Auslegung riskiert man overflows, das wird auch noch ewig so weitergehen und ist nicht auf pdf begrenzt überall wo komplexe Formate geparst werden müssen hat man das Problem. Siehe Medienplayer, da gibts auch zig streng definierte Formate, teure Standardsoftware schreibt aber nicht exakt das Format, es gibt aber eine Menge von dieser software erzeugten Content also muss man den Player bzw. den Parser für das Format an den Murks anpassen weil man sonst ständig Beschwerden von Usern bekommt dass der Player nicht richtig funktionieren würde. Immerhin nutze man ja das teure Standardprogramm für solche Dateien, das schreibt per Definition korrekt.
Oder Office, das kommt ja nicht mal mit seinen eigenen älteren Dokumenten klar,…. Da sind überall Sicherheitslücken eingebaut – auf Jahre!


Hadmut
21.7.2011 13:26
Kommentarlink

@kalle: Nutzt halt nur nichts, wenn man bei den modernen graphischen Unix-Desktops das Zeug direkt anklickt und keine Konsolenausgaben mehr sieht.


Mephane
21.7.2011 13:07
Kommentarlink

Danke für die Erläuterungen. Ich hatte mich bisher nicht mit dem Aufbau von PDF-Dateien befasst, aber was du sagst erklärt ganz gut wie es zu diversen Sicherheitslücken kommen kann. Ich frage mich aber auch, wie man auf die schlaue Idee kommt, die Größenangaben der Stream *hinter* die Streams zu plazieren, anstatt das Dateiformat streng linear von vorne nach hinten parsbar zu gestalten.

Was mich nur etwas verwirrt jetzt: Du sagst, die Offset-Tabelle steht am Ende einer PDF-Datei, wodurch Browser einzelne Seiten zeigen können ohne die ganze Datei zu laden. Wie ist das zu verstehen? Wenn der Browser die Datei herunterlädt, bekommt er doch die Tabelle zuletzt, und weiß dann erst, wo die gewünschte Seite zu finden ist, oder?


Hadmut
21.7.2011 13:15
Kommentarlink

@Mephane: Ich habe gerade oben noch eine Ergänzung eingefügt, ab PDF 1.5 können die Referenzen auch anders aufgebaut sein.

PDF wurde zu einer Zeit entwickelt, als Computer noch wenig Speicher hatten. PDF ist daher so aufgebaut, daß man es nicht komplett oder linear in den Speicher lesen muß, und daß man es auch zum schreiben nicht komplett im Speicher aufbauen muß. Software kann die Objekte erst mal rausschreiben und dann am Ende der Datei (bzw. ab 1.5 irgendwo zwischendrin) die Indizes schreiben.

Eine Software die liest, springt erst mal ans Ende der Datei (seek), und holt sich die Tabelle (bzw. ab 1.5 die Angabe, wo die Tabelle mittendrin zu finden ist). Wenn die Software dann eine Seite anzeigen soll, holt sie sich aus dem PDF nur die Teile, die sie gerade braucht, muß aber nicht die ganze Datei in den Speicher laden.

So ähnlich funktioniert das auch, wenn der Web-Browser mit eingebautem PDF-Reader auf eine PDF-Datei zugreift. Bemerkenswerterweise muß der Browser nicht die ganze Datei holen. Man kann im HTTP-Request auch angeben, daß man nur einen Ausschnitt aus einer Datei haben möchte. Und tatsächlich holen sich die Browser bei großen PDFs erst mal nur Teile der PDF-Datei um sie schnell anzuzuzeigen. Erst danach oder wenn der Nutzer blättert, wird der ganze Rest geholt. Kann man an Webserver-Logs ersehen.


Usul
21.7.2011 16:11
Kommentarlink

Das mit der stillen Fehlertoleranz von Programmen nervt mich auch ein bisschen. Ist manchmal gruselig, was in der ~/.xsession-errors so alles durch die Gegend poltert und man davon nichts mitbekommt …

Eine Anwendung, die fehlerhafte Dokumente einfach so verweigert, fände ich aber auch nicht wirklich gut. Früher war es z. B. bei Opera so, dass wenn eine HTML-Seite sich als XHTML Strict (oder so ähnlich) deklariert hat, aber trotzdem Fehler darin waren, der Anwender eine übelst abschreckende XML-Fehlermeldung zu sehen bekam. Das Verhalten war zwar rein technisch korrekt, aber nicht benutzerfreundlich.

Was mir vorschwebt, wäre so eine Art (nerviger) Hinweis, ein rotes Ausrufezeichen in irgendeiner Statusleiste oder dergleichen, was darauf hinweist, dass das Dokument Fehler enthält. Bei validen Dokumenten gibt es als Belohnung ein grünes Häkchen. Das würde zumindest das Problem ein bisschen sichtbar machen, ohne den Nutzer jetzt gleich mit kompletter Ablehnung zu begegnen. Ich stelle mir das analog zu dem Hinweis mit bei unsicheren, weil gemischten HTTPS/HTTP-Seiten vor. Die kann man prinzipiell auch ansehen und benutzten, aber man bekommt den Fehler aufs Auge gedrückt. Und es gibt genug Nutzer, die das nervt oder verunsichert, und die dann den Erstellern des Dokuments auf die Nerven geht.


sachichdoch, back to ps


anonym
21.7.2011 18:08
Kommentarlink

“Was mir vorschwebt, wäre so eine Art (nerviger) Hinweis, ein rotes Ausrufezeichen in irgendeiner Statusleiste oder dergleichen, was darauf hinweist, dass das Dokument Fehler enthält. Bei validen Dokumenten gibt es als Belohnung ein grünes Häkchen.”

“Dieses Dokument wird im PDF/A-Modus angezeigt.” zeigt der Reader ja auch ganz stolz an …

BTW: PDFs, mit denen PDF Xpress von der IEEE zufrieden ist, habe ich auch noch nicht hinbekommen …


Ben
21.7.2011 20:15
Kommentarlink

Zu dem Phänomen, dass in einigen PDFs am Ende HTML klebt, gibt es eine einfache Erklärung. Mit Speicherlecks hat das nichts zu tun.

Die PDF “Generierung” (häufig wird eh über eine externe lib aus HTML konvertiert) wird meist nachträglich in bestehende Webanwendungen eingebaut. Und zwar wird es dann meist ganz am Anfang der Anfrage-Verarbeitung reingehunzt. In PHP sähe das z.B. so aus:

——– SCHNIPP ————-
// HTML Ausgabe für die Anfrage generieren und in $output schreiben
$output = …

// Hoppala, wir brauchen ne PDF!
if ($pdf) {
header (‘Content-Type: application/x-pdf’);
echo convertHtml2Pdf($output);
// Alternativ, wenn es um eine bestehende PDF handelt, die weitergereicht werden soll:
//// readfile (PFAD_ZUR_PDF);
}

// … jede Menge anderer Stuff …

echo $output;

——– SCHNAPP ————-
(Hier nochmal in schön: http://snipt.org/xlonl )

Fällt’s auf? Das Programm terminiert nicht nach dem Ausgeben des PDF-Inhalts, sondern marschiert durch und gibt dann natürlich nochmal den HTML Code aus, statt dort abzubrechen bzw. die Seitenausgabe zu verhindern. Es wäre ja kein Problem, das zu fixen, aber da die Entwickler das – dank der Viewer, die die PDF auch so fressen – nicht bemerken, wird es häufig nicht korrigiert.


Ralf Muschall
21.7.2011 22:58
Kommentarlink

PDF ist sowieso eine Seuche. Statt es zu erfinden, hätte Adobe die Macken von PS beheben sollen (wie z.B. die Erfordernis, alle Seiten durchzulesen, wenn man eine weit hinten anzeigen will).

Siehe auch http://events.ccc.de/congress/2010/Fahrplan/events/4221.en.html
(der Link zum PDF dort ist kaputt, es ist z.B. bei http://blog.fireeye.com/files/27c3_julia_wolf_omg-wtf-pdf.pdf).


Hadmut
21.7.2011 23:21
Kommentarlink

@Ralf Muschall:

Ich hab früher auch sehr viel mit Postscript gemacht, sogar Programme in Postscript geschrieben, kenne also die Unterschiede.

PDF ist sehr stark an Postscript orientiert, in vielen Aspekten nahezu gleich, die Hauptunterschiede sind, daß PDF im Gegensatz zu Postscript keine Programmiersprache sondern nur eine „dumme” Liste von Graphikanweisungen ist, daß es viel stärker komprimiert ist und die (zu Postscript meist äquivalenten) Operatoren kürzere Namen haben, Kompression mit drin ist und es eben auf freies Blättern ausgelegt ist.

PDF war das Ergebnis davon, bei PS die Macken zu beheben. Daher kann man Adobe nicht vorwerfen, daß sie lieber PS hätten verwenden und es verbessern sollen. Denn genau das ist ja PDF. Im wesentlichen ein auf die Graphikanweisungen reduziertes Postscript, mit einem Framework außenrum, um das Zeug besser zu strukturieren und die Seiteninhalte direkt zu finden.


kryptart
22.7.2011 16:18
Kommentarlink

@usul Dillo, ein kleiner Web-Browser hat was in der Art. in einer Statuszeile wird die Anzahl der Fehler des Html-Documents angezeigt.


Ralf hat ja schon den Vortrag zum Thema verlinkt. Das Problem ist nicht unbedingt das Dateiformat (obwohl die Spezifikation sicherlich deutlich genauer sein könnte), sondern die Software, die PDFs verarbeitet: Die ist zum überwiegenden Teil grottenschlecht. So grottenschlecht, daß sogar Adobe keine sicheren Interpreter schreiben kann, sondern ihren Code sandboxen muß (genau das machen sie im Adobe Reader 10). Das wird natürlich noch dadurch verschärft, daß die Adobe Software inzwischen nicht nur ein PDF darstellt, sondern nebenbei noch JavaScript und Flash ausführt. Und für Flash möchte man eigentlich einen Blitzableiter…


Hadmut
23.7.2011 2:20
Kommentarlink

Wenn die Software ein PDF falsch darstellen oder irgendwie abbrechen würde, ging’s ja noch. Aber daß die sich da Sicherheitslücken einfangen, mit denen man in das System eindringen kann, ist wirklich übel.

iOS (Apple iPhone, iPad) hatte ja auch gerade so ein Ding drin, wo bei der Interpretation von in PDF eingebetteten TrueTypeFonts (die im Gegensatz zu Flash und JavaScript wirklich benötigt werden) ein Pufferüberlauf möglich war und man das iPad aufbrechen konnte.


Stefan W.
23.7.2011 5:57
Kommentarlink

Mit xslt erzeuge ich aus einer Datei, die ich selbst erzeuge, einen Report, der in ein PDF verwandelt wird, und von xpdf und evince schön angezeigt wird.

Aber der Kunde bekommt leere Seiten zu sehen (Acroread). Also Acroread installiert: leere Seiten!

Wenn ich mit xlst statt pdf ps erzeuge, und mit ps2pdf daraus pdf, dann klappt es auch mit dem Acroreader.

Leider sagt aber der Acroreader nicht, was da kaputt ist, sondern er zeigt einfach Murks an. Das hilft mir auch wenig, den eigentlichen Fehler zu finden.


ennomitnimmt
24.7.2011 18:23
Kommentarlink

Schön auch wie xpdf gleich meinen Windowmanager bei Absturz


enno
24.7.2011 18:27
Kommentarlink

Wurstfinger – siehe letzter Kommentar. Die Placement-Regeln von Stumpwm reagieren sehr rigoros wenn xpdf mit Speicherzugriffsfehler abschmiert. Das kann schon Nerven kosten, wenn bei Anzeige von fehlerhaften PDFs der Fenstermanager mitgerissen wird 🙁
Muss ich mir auch mal genauer ansehen