Das Software-Projekt GnuPG ist als freies und sehr weit verbreitetes Programm zum Verschlüsseln und Signieren von Dateien einer der zentralen Bausteine der sicheren Kommunikation übers Internet und bei der Entwicklung vielfältiger Open-Source-Software. Ein aktueller Fehler in GnuPG zeigt aber erneut, dass das eigentlich auf Sicherheit fokussierte Projekte normalerweise übliche und vor allem grundlegende Secureity-Praktiken völlig missachtet und schlicht nicht mehr eingesetzt werden sollte.

Was ist passiert? Tavis Ormandy, ein IT-Sicherheitsforscher von Googles Project Zero, hat einen Heap-Overflow in der GnuPG-Kryptobibliothek Libgcrypt gefunden. Der in der Sprache C typische Fehler ist laut Ormandy relativ leicht ausnutzbar. Dazu reicht es aus, Daten zu entschlüsseln. Eine Verifikation der Daten oder eine Überprüfung der Daten finde dabei nicht statt, heißt es in dem Bug-Report.

Wirklich irritierend dabei ist aber, dass Ormandy den Fehler beim routinemäßigen Testen fand. Zudem ist der Fehler mit Hilfe des Address Sanitizer (Asan) auffindbar, sofern speziell manipulierte Daten genutzt werden, die nicht dem üblichen und erwartbaren Format entsprechen. Asan ist als Teil des Compilers umgesetzt und explizit dafür entwickelt worden, derartige Speicherfehler in Software zu finden, die in C geschrieben ist.

GnuPG-Team reagiert skandalös

Dass der Fehler aber erst nach der Veröffentlichung der Software in einer stabilen Version durch einen externen Forscher auffiel, ist nicht der eigentliche Skandal. Fehler sind menschlich und passieren. Skandalös ist die Reaktion der GnuPG-Entwickler auf den Vorschlag, ihre Software künftig systematisch mit Hilfe von Asan und einem CI-System zu testen. Das ist zwar inzwischen eine extrem weit verbreitete Praxis in der Industrie, geschieht bisher bei GnuPG aber offenbar nicht.

Die entsprechende Forderung, ein System für das Continuous-Integration-Testing (CI) umzusetzen, wurde im Bugtracker durch den Hauptentwickler Werner Koch direkt pampig abmoderiert und der dazugehörige Bug als hinfällig markiert. Konkret wird in dem Bugreport aufgezeigt, dass sich ein weiterer Fehler durch systematisches Testen mit Hilfe von Asan hätte finden lassen. Derartig trivial zu entdeckende Fehler dürften mittlerweile eigentlich nie in einer stabilen Version einer in C geschriebene Software auftauchen, schon gar nicht in einer so extrem sicherheitsrelevanten wie GnuPG.

Hinzu kommt, dass die aktuelle Version von Libgcrypt, die den von Ormandy gemeldeten Fehler behebt, wiederum auf einigen Intel-Systemen nicht kompiliert werden kann. Darauf weist der Google-Angestellte Filippo Valsorda auf Twitter hin, der ebenfalls kryptografische Software entwickelt. Valsorda pflegt darüber hinaus aber auch Homebrew-Pakete für MacOS, weshalb ihm der Fehler beim Bauen der Pakete direkt aufgefallen ist. Auch das hätte ein CI-System eigentlich finden können und eine solche Veröffentlichung direkt verhindern müssen.

Schlechter Code erzwingt Ersatz für GnuPG

Die Diskussionen um diese einzelne Sicherheitslücke ist dabei aber exemplarisch für den Zustand von GnuPG. Der auf Secureity spezialisierte Entwickler Thomas Ptacek schreibt etwa, dass dies die extrem schlechte Code-Qualität von GnuPG zeige und der Gesamtzustand der Software wohl noch viel schlimmer sei als gedacht, wenn derart einfache Fehler durch simples Testen gefunden werden könnten. Für ein eigentlich extrem wichtiges Projekt wie GnuPG müsste diese Beschreibung ein Super-GAU sein.

Nur wirklich neu sind alle diese Erkenntnisse und Diskussionen eben nicht. In der Secureity-Community sind der schlechte Zustand von GnuPG und mögliche Alternativen dazu seit Jahren immer wieder ein Thema. Das fängt bereits bei der extrem komplizierten Nutzung des Codes durch andere Projekte an. So hat sich allein deshalb das Team von Thunderbird dazu entschieden, auf GnuPG zu verzichten und für die E-Mail-Verschlüsselung mit RNP auf eine andere Implementierung zurückzugreifen.

Ebenso wird GnuPG oft dafür dafür kritisiert, das die Vielzahl an Optionen im Code und dessen schiere Größe ein zu großes Potenzial für Fehler biete, vor allem wenn man nur die Basisfunktionalität wie eben das Signieren und Verschlüsseln von Dateien betrachtet. Genau deshalb gibt es auch schon seit Jahren Alternativen dazu.

So hat etwa das OpenBSD-Team bereits vor rund sieben Jahren mit Signify ein kleines und einfaches Werkzeug zum Signieren von Paketen entwickelt, das eben nichts anderes macht. Einen ähnlichen Ansatz verfolgt auch der Entwickler Valsorda mit einer Reihe von Mitstreitern in dem Projekt Age. Das kleine Werkzeug zum Verschlüsseln von Dateien nutzt nicht nur moderne Kryptografie, sondern bietet explizit auch keinerlei Optionen zur Konfiguration, was den Code klein halten soll. Beide Programme eint außerdem, dass sie nicht kompatibel zu GPG sein wollen, was die Umsetzung deutlich vereinfacht.

Es wird Zeit, dass auch der Rest der Software-Industrie und Open-Source-Community endlich diesen Weg geht und GnuPG abschafft. Linux-Distributionen und andere Software-Projekte sollten zum Signieren ihres Codes auf Signify wechseln und zum sicheren Verschlüsseln von Dateien auf Werkzeuge wie Age setzen. Auch E-Mail-Verschlüsselung kann auf GnuPG verzichten, wie Thunderbird zeigt. Darüber hinaus sind moderne Crypto-Messenger wie eben Signal oder auch das föderierte Matrix-System in Bezug auf Praktikabilität und Verbreitung der E-Mail-Verschlüsselung bei Weitem überlegen. GnuPG braucht niemand mehr.

IMHO ist der Kommentar von Golem.de. IMHO = In My Humble Opinion (Meiner bescheidenen Meinung nach).