Software::Security
Shellshock-Sicherheitslücke im Rückblick
Die Sicherheitslücke in Bash, die den Namen »Shellshock« erhielt, ist nun endgültig behoben. Der Sicherheitsforscher David A. Wheeler zieht nun Bilanz. Er stellt im Detail dar, wie die Lücke entstand, warum sie so schwer zu finden war, welche Restrisiken verbleiben und was unternommen werden kann, um ähnliche Probleme in Zukunft zu vermeiden.
Andreas Lindh
Der Sicherheitsforscher David A. Wheeler stellt
in seinem Artikel die zeitliche Entwicklung von »
Shellshock« im Detail dar. Die Sicherheitslücke bestand darin, dass die Shell
bash bei ihrer Initialisierung die Umgebungsvariablen einliest. Der Parser enthielt an dieser Stelle mehrere Fehler, die ausgenutzt werden konnten, wenn man einer Umgebungsvariablen eine Funktionsdefinition zuweist. Folgt auf die Funktionsdefinition zusätzlicher Shell-Code, wurde dieser unmittelbar ausgeführt. Das war eine Sicherheitslücke in allen Situationen, in denen ein Angreifer den Inhalt von Umgebungsvariablen kontrollieren kann, darunter auch CGI-Skripte, die die Bash direkt oder indirekt verwenden, oder Netzwerk-Initialisierungsskripte, die Daten von einem bösartigen DHCP-Server erhalten.
Als der ursprüngliche Bash-Entwickler Brian Fox im August 1989 den Import und Export von Funktionen einbaute, ahnte niemand, dass dies ein Sicherheitsproblem werden könnte. Die relativ selten genutzte Funktionalität wurde mit Bash 1.03 am 1. September 1989 zum ersten Mal offiziell verfügbar. 25 Jahre lang bemerkte niemand das Problem. Wheeler führt dies auch darauf zurück, dass die Funktionalität nahezu undokumentiert und kaum jemandem bekannt war. Maximal ein Satz in der durchaus nicht kurzen Bash-Dokumentation bezieht sich darauf. Wheeler fordert daher alle Entwickler auf, ihre Software besser zu dokumentieren. Falls sie Bedenken haben, mit ihrer Dokumentation eine Funktionalität festzuschreiben, die sie noch nicht als endgültig oder nicht für Endanwender geeignet ansehen, sollten sie sie wenigstens in einem Design-Dokument festhalten, wo sie sich Änderungen ausdrücklich vorbehalten können.
Stéphane Chazelas bemerkte das Problem am Vormittag des 12. September 2014 und war sich unmittelbar der Tragweite bewusst. Am Nachmittag informierte er das Bash-Projekt und einige Distributionen über private Mails. In den folgenden Tagen arbeiteten alle Beteiligten an einer Korrektur, die in einer koordinierten Veröffentlichung am 24. September um 14 Uhr mündete, bei der Details zu der Lücke und zeitgleich Patches und aktualisierte Pakete freigegeben wurden. Das Problem schien damit für die Entwickler ausgestanden.
Das war ein Trugschluss, denn wie sich schnell herausstellte, war die Korrektur unvollständig. Es wurden Wege gefunden, sie zu umgehen. Erst mit dem dritten Patch für Bash war das Problem endgültig behoben. Drei weitere Patches folgten, die jedoch nur noch Details verbesserten. Die Distributionen, die schnell das erste Update herausgegeben hatten, mussten noch einmal eine verbesserte Version nachlegen.
Dabei gingen die Distributionen unterschiedlich vor. Manche verwendeten Patches, die denen ähnlich waren, die schließlich in die offizielle Bash gelangten. Andere, insbesondere die BSDs, setzten auf einen von Christos Zoulas (NetBSD) entwickelten Patch, der die Funktionalität optional macht. Alle Varianten lösen das Problem aber endgültig. Die offizielle Lösung in der Bash besteht darin, dass Funktionen nur noch Variablen zugewiesen werden können, die mit BASH_FUNC_ beginnen und mit %% enden. Das ist zwar nicht rückwärtskompatibel, aber die wenigen Nutzer der Funktionalität können ihre Skripte anpassen. Apple verwendet in Mac OS X eine Variante mit dem Präfix __BASH_FUNC< und dem Suffix >() mit der Begründung, dass damit keine Funktionen über HTTP-Header übergeben werden können. Wheeler hält diese Lösung für riskanter und anfällig für neue Probleme. Einen anderen Weg ging Akamai, das die Funktion mit einem eigenen Patch komplett eliminierte.
»Shellshock« wurde von den meisten Organisationen als Sicherheitslücke der schwerwiegendsten Kategorie eingestuft. Dabei gibt es keine größeren bekannten Webanwendungen, die die Bash verwenden. Das Problem ist eher, dass es eine unbekannte Zahl von kleinere CGI-Skripten gibt, und eine weitere unbekannte Zahl von Anwendungen die Bash über system() oder ähnliche Funktionen aufruft. Der beste Test, ob man eine verwundbare Version der Bash besitzt, ist die Zeile
env foo='() { echo not patched; }' bash -c foo
Debian und Ubuntu waren etwas weniger anfällig für die Lücke, weil sie als nichtinteraktive Shell standardmäßig dash verwendet. Diese ist POSIX-konform, aber viel kleiner und schneller als Bash. Wer jedoch erweiterte Funktionen in seinen Skripten benötigt, kann immer noch explizit die Verwendung der Bash anfordern.
Auch wenn »Shellshock« komplett behoben ist, bleibt das Problem, dass manche Systeme im Internet immer noch nicht aktualisiert wurden. Ferner gibt es eine unbekannte Zahl von Systemen, bei denen ein Update nicht einmal vorgesehen ist. Das ist natürlich ein generelles Problem, das nichts mit »Shellshock« zu tun hat. Für das Bash-Problem haben Solar Designer und andere eine Methode vorgestellt, einen Patch der Binärdatei vorzunehmen.
Sicherheitslücken wie »Shellshock« sind laut Wheeler extrem schwer zu entdecken, aber es ist nicht unmöglich. Sicher wird es einige Anstrengungen geben müssen, bestehende Programme zu untersuchen. Wie man künftige Lücken vermeidet, ist jedoch ebenso wichtig, und das nimmt in Wheelers Artikel breiten Raum ein. Wheeler mahnt die bereits erwähnte bessere Dokumentation an. Diese sollte dann als Grundlage für eine Sicherheitsanalyse dienen. Entwickler sollten mit Namensräumen arbeiten, beispielsweise eigenen Verzeichnissen. Daten und Code sollten getrennt werden, also beispielsweise kein JavaScript in HTML-Dokumenten. Der Import von Daten und Code sollte nur auf explizite Anforderung erfolgen, wie beispielsweise die BSD-Lösung für Shellshock. Funktionalität sollte minimiert werden (Dash statt Bash). Die Verwendung von Komponenten wie der Bash sollte vermieden werden, wenn es Alternativen gibt. Selten genutzte Funktionen sollten eliminiert werden. Eine künftige Möglichkeit wäre es, über Variablen Buch zu führen, die externe und potentiell unsichere Daten enthalten (Tainting). Hersteller und Betreiber von Systemen sollten darauf vorbereitet sein, Updates vorzunehmen.
){kind=logo}
