Mangelnde Eingabeprüfung ist eine der häufigsten Schwachstellen in Software. In diesem Fall ließ sie sich nutzen, um den kompletten Maildienst zu blockieren.
Der Trick ist alt, aber leider fallen immer und immer wieder Programmierer auf ihn herein: Ein Angreifer übergibt einem Programm Eingaben, mit denen die Software nicht rechnet – und die Daten landen dann an Orten, die dafür nicht vorgesehen sind. Eine Spielart dieser Methode ist der so genannte Pufferüberlauf (Buffer Overflow), bei dem über die Grenzen eines Zwischenspeichers hinaus geschrieben wird.
In harmlosen Fällen führt das vielleicht zu einem Absturz des Programms. Verfolgt der Attentäter aber böse Absichten und stellt sich geschickt an, dann kann er mit Hilfe der überraschenden Eingaben Speicherbereiche mit neuen Inhalten so überschreiben, dass sie nicht allein Daten verfälschen, sondern beispielsweise auch die Rücksprungadresse einer Subroutine überschreiben. In der Folge wird die Programmausführung an einer ganz anderen Stelle fortgesetzt.
So lässt sich ausführbarer Code einschmuggeln, der mit den Rechten des übertölpelten Prozesses läuft. Das kann dem Angreifer unter Umständen weitreichende Rechte einbringen, schlimmstenfalls liefert der sorglose Programmierer ihm so das ganze System aus.
Fehler in formail
Kürzlich hat der alte Trick wieder funktioniert. Diesmal (CVE-2014-3618) bei »formail« , einem kleinen, zu Procmail gehörenden Utility, das als Filter übergebene Mails in das Mailbox-Format konvertiert. Darüber hinaus beherrscht es noch ein paar zusätzliche Kniffe, beispielsweise die automatische Generierung von Reply-Headern oder das Extrahieren einzelner Header-Felder.
Übergibt ein entfernter Nutzer »formail« nun Mails mit speziell präparierten Adressen, läuft der Heap – eine spezielle, oft baumartig organisierte Datenstruktur – über und das Programm stürzt ab. Den Effekt kann der Angreifer mindestens für eine DoS-Attacke nutzen, mit der er den Maildienst durch fortwährend provozierte Abstürze lahmlegt.
Die letzte Ursache für Pufferüberläufe und ähnliche Tricks liegt übrigens in der Von-Neumann-Architektur unserer Rechner, derzufolge Daten und Programm im gleichen Speicher liegen. Würde man sich daran nicht halten und den Speicher in strikt getrennte Bereiche segmentieren – wie das unter anderem das zu seiner Zeit fortschrittliche OS/2 versucht hat –, wären Überläufe durch Eingaben unmöglich. Auch interpretierte Sprachen sind relativ sicher, weil hier der Interpreter immer die volle Kontrolle über die Speicherverwaltung hat.
Kontrolle ist besser
Wer weder eine Interpretersprache noch OS/2 verwendet, für den gibt es nur eins: Traue keiner Benutzereingabe! Jede mögliche Eingabe ist nicht nur streng daraufhin zu überprüfen, ob sie plausibel ist, sondern auch, ob sie nach Datentyp, Wertebereich und Länge den Erwartungen entspricht.
Dabei checkt der Programmierer zum Beispiel, ob nicht erlaubte Zeichen enthalten sind, ob Ziffern übermittelt werden, wo numerische Eingaben zu erwarten sind, ob die Angaben konsistent sind, ob Dateien, auf die Bezug genommen wird, existieren, ob die Datenformate passen, ob Limits eingehalten werden, ob Werte, für die dies verlangt wird, einzigartig sind, ob die referenzielle Integrität einer Datenbank gewahrt bleibt, ob die Angaben vollständig sind oder ob Referenzen auf andernorts gespeicherte Daten einem Cross-Check standhalten.
Das ist eine stattliche Reihe, aber fällt die Eingabe auch nur durch eine dieser Kontrollen, ist sie zu verwerfen.





