News

Erste Vermutungen zur Ursache der Xerox-Scanfehler

Die folgenden Informationen sind auch in den Originalartikel eingepflegt, damit ihr alles auf einen Blick habt.

Der Gedanke einer zu hart eingestellten Bildkompression und der Wiederverwendung einzelner Bild-Patches scheint so falsch nicht gewesen zu sein. Aus mehreren Zuschriften geht die Mutmaßung hervor, dass in den Geräten für PDF-Scans die JBIG2-Kompression für Bilddaten zum Einsatz kommt. Diese erzeugen ein Wörterbuch an ähnlichen Bild-Kacheln (Patches), die dann nach Bedarf mehrfach verwendet werden, solange der dadurch produzierte Fehler nicht zu groß wird. Ich finde das sehr plausibel.

Das würde auch erklären, warum der Fehler primär auftritt, wenn man Text am Rande der lesbaren Auflösung scannt. Dann liegt man größenmäßig in der Nähe der verwendeten Patches, und ganze Buchstabenblöcke werden sauber ausgeschnitten und vertauscht, so wie oben. Statische Strukturen wie Linien um die Buchstaben sind dann sogar hilfreich, und so kommen dann auch so sauber ausgetauschte Quadratmeterzahlen zustande.

Es sieht nun so aus, als wäre JBIG2 im vorliegenden Fall vom Hersteller zu radikal eingestellt, bzw. eine zu große Patchgröße gewählt. Eine Patchgröße zu wählen, in der ganze, lesbare Zeichen unterbringbar sind, wäre extrem fahrlässig. Es würde auch ein Licht darauf werfen, wie die Geräte getestet worden sind – denn gerade der Einfall, bei Einsatz eines solchen Kompressionsverfahrens schlecht aufgelöste Zeichen auf Abweichungen zu testen, drängt sich eigentlich geradezu auf. Man darf also gespannt sein, wann Xerox sich äußert – auf jeden Fall danke erstmal, dass ihr die Sache so verbreitet, ich finde das sehr nützlich. Macht weiter so! Und ich freue mich in jedem Fall über weitere, hilfreiche Zuschriften.

Update: Kommt grad per Mail rein :-) – Danke, Boris!

Xerox-Scankopierer verändern geschriebene Zahlen

Vorabanmerkungen:

  • Eine (lange nicht erschöpfende) Presseschau habe ich anlässlich meiner Gastvorlesung zum Thema hier zusammengestellt. Ich bin selbst überrascht, wie viele Artikel es gibt.
  • Eine Zeitleiste der ganzen Angelegenheit gibt es weiter unten. Darin kann man sich einen Überblick verschaffen, und findet auch die relevanten Blogartikel verlinkt. Daraus geht auch klar hervor, dass ich Xerox sehr viel Zeit gelassen habe, also nicht einfach mit der Sache an die Öffentlichkeit gegangen bin. Das ist mir wichtig, weil ich erstmal versuche, im nicht-öffentlich auf Leute zuzugehen, wenn ich etwas zu beanstanden habe.

Video und Folien zu meinem Vortrag "Traue keinem Scan, den du nicht selbst gefälscht hast" (31C3)

Hier gibt es auch noch die Vortragsfolien.

Hier könnt ihr mir Feedback über den Vortrag geben! Das ist mir wichtig, danke! :-) (Achtung: 5 ist das beste, 1 ist das schlechteste, das sind keine Schulnoten.)

Einleitung

In diesem Artikel dokumentiere ich ausführlich, wie weit verbreitete Firmen-Scankopierer der Firma Xerox bei gescannten Seiten Ziffern, Zahlenreihen oder andere Bildfragmente unvorhersehbar vertauschen/ersetzen – und zwar nicht aufgrund irgendwelcher Texterkennung, sondern richtig hart in den Pixeldaten. Das Ergebnis sind Dokumente, die subtil falsch sind, aber perfekt aussehen – so, dass man es auf den ersten Blick nicht bemerkt. So etwas kann extrem gefährlich sein oder sogar Menschenleben kosten. Der Phantasie sind keine Grenzen gesetzt:

  1. Abrechnungen, die plötzlich nicht mehr stimmen.
  2. Baupläne mit vertauschten Quadratmeterzahlen.
  3. Falsche Ingenieurspläne, die wiederum Menschenleben gefährden würden (stellt euch vor, eine Autobahnbrücke hat in der Statik einen Zahlendreher verbaut).
  4. Arzneimitteldosierungen mit Zahlendrehern, eigentlich noch schlimmer.

Ihr seht schon: Was sich zunächst locker anhört, ist absolut kritisch und kann schnell lebensgefährlich werden. Es handelt sich um einen acht (!) Jahre alten Bug, der nach Händlerinformationen hunderttausende Xerox-Multifunktionskopierer weltweit betrifft. Mehrere große Gerätefamilien sind betroffen (eine Liste gibt es weiter unten). Jeder, der diese in den letzten acht Jahren eingesetzt hat oder jetzt noch einsetzt, muss sich fragen:

  • Wieviele fehlerhafte Unterlagen, die auf den ersten Blick richtig aussehen, habe ich in den letzten Jahren gespeichert oder gar an dritte herausgegeben?
  • Sind durch diese denkbaren Fehler Menschen oder Vermögenswerte gefährdet?
  • Kann ich für diese Fehler verantwortlich gemacht werden?

Bis zur Behandlung des Fehlers in meinem Blog war er nicht entdeckt oder veröffentlicht. Seine Tragweite entfaltete sich auch erst in Laufe meiner verschiedenen Blogartikel, die von den Massenmedien aufgegriffen und verbreitet wurden. In welcher Reihenfolge was geschah, lässt sich anhand der nachfolgenden Zeitleiste sehen. Es waren zwei interessante Wochen, das kann ich euch versprechen. :-)

Der Rest des Artikels ist wie folgt gegliedert.

  • Es wird an einer Zeitleiste beschrieben, wie die Angelegenheit sich entfaltet hat
  • Es wird an konkreten Beispielen beschrieben, wie der Fehler entdeckt wurde, und wie subtil er auftritt. Weil schwer zu glauben ist, dass ein Scankopierer Zahlen verdreht, liefere ich natürlich Beweismaterial mit.
  • Danach kommt eine Liste der betroffenen Kopierer.
  • Es folgt eine grobe Anleitung, wie sich der Fehler reproduzieren lässt.
  • Zuletzt gibt es eine kurze, laienhafte rechtliche Würdigung der rechtlichen Folgen. Kurzform: Die letzten 8 Jahre an PDF-Scans von betroffenen Geräten kann nicht nur Fehler enthalten, sie sind anscheinend auch rechtlich komplett wertlos, und zwar unabhängig davon, ob Fehler tatsächlich nachgewiesen werden.

Open Sans

Ich habe die Schriftart mal testweise auf Open Sans umgestellt (danke an Stefan, der mich auf die Schriftart hingewiesen hat). Die Schriftart wird bei denjenigen unter euch, die sie nicht ohnehin auf dem System haben, als WOFF nachgeladen, sofern euer Browser das unterstützt. Das ganze ist ein Test für ein späteres Redesign der Seite.

Mal gucken ob es euch (und mir) gefällt. Im Moment schwanke ich noch.

Neuer Server

Der Traffic der Seite ist ganz langsam gewachsen. Darum ist die Seite jetzt auf einen neuen Server umgezogen, was erfreulicherweise zu einem merkbaren Geschwindigkeits-Upgrade geführt hat.

Vorher lag sie auf einem kleinen Atom230-Rootserver. Jetzt läuft sie auf einem netten Intel Core i3-2130 mit 3.4 GHz und 8GB RAM – und da ist die Seite auch nicht direkt reingezogen, sondern auf dem Server läuft ein Xen, und dort hat die Seite eine eigene Virtual Machine für sich. Geblieben ist der Webserver Nginx.

Den Atom hatte ich noch auf Arch Linux laufen, weil ich es damals schön fand. Leider verursacht Arch, sofern man nicht alle vier Femtosekunden die Rolling Updates installiert, ziemlich Wartungsaufwand. Darum läuft die Virtual Machine für die Webseite jetzt auf einem schönen, neuen Debian Wheezy. Und weil Wheezy ja neu ist und ich mir daher noch nicht ganz über die Sicherheit im klaren bin, läuft es hinter einer Router-VM. Das gibt mir auch die Möglichkeit, unerwünschten Traffic rauszurouten, bevor er CPU-Load produziert. So weit, so schön.

Jetzt sollte man meinen, man rsynct einfach sein Dokuwiki (denn darauf läuft die Seite ja) vom einen auf das andere System, und alle sind glücklich. Wer das denkt, kennt mein Karma nicht (huhu, CK! :-)). Für die Blog-Inhalte nutze ich nämlich das BlogTNG-Plugin für Dokuwiki. Damit hatte ich 2011 das alte Blog-Plugin abgelöst, weil es deutlich schneller und robuster ist, denn es speichert die Metadaten des Blogs in einer SQLite-Datenbank.

Leider ist BlogTNG nun aber nicht besonders super gewartet, und so unterstützt es offiziell leider nach wie vor nur SQLite2. Jetzt fällt mir auch wieder ein, dass das der Grund war, warum ich unter Arch damals nicht mehr alle vier Femtosekunden die Updatefunktion ausgeführt hatte. Irgendwann kam nämlich das Update auf PHP 5.4, und damit wurde der SQLite2-Support offiziell gestrichen. Auf Wheezy gibt es aber nur noch PHP 5.4. Verflucht! Glücklicherweise gibt es einen inoffiziellen SQLite3-Branch für BlogTNG, also flugs die Datenbank konvertiert und den verwendet. Scheint zu funktionieren alles. Wenn ihr Fehler entdeckt, sagt bitte Bescheid.

Irgendwann setze ich auch noch das Dokuwiki selbst neu auf, da ist auch noch irgendeine Langsamkeitsquelle drin. Im Moment schmeiße ich einfach mit mehr CPU-Power auf das Problem, was ja nicht der Weisheit letzter Schluss sein kann. Aber das passiert dann in Tateinheit mit einem neuen Template, denn das gerade verwendete Minima scheint auch nicht mehr so prall gewartet zu werden. Dann muss ich aber auch einen neuen Stylesheet schreiben. Hm. We'll see. Genug geflucht und gefrickelt für heute jedenfalls.