ShellShock Hype und was man dagegen tun kann

Leider ist die Berichterstattung über ShellShock nicht mehr sachlich, sondern wird immer reißerischer. Insbesondere der Vergleich mit Heartbleed ist wohl unangebracht. Schließlich handelt es sich hierbei mehr oder weniger um ein Feature von BASH.



Ich möchte nicht unterschlagen, dass es in Verbindung mit einem bösartigen DHCP-Server (CVE-2014-6271) Möglichkeiten gibt, einen Linux Client zu übernehmen - allerdings muss man seinem DHCP-Server sowieso vertrauen, schließlich bekommt man dort Gateway und Nameserver...

Die wahrscheinlich größte Gefahr dürfte derzeit von Webservern ausgehen, die über eine CGI-Schnittstelle eine BASH ausführen. Das können CGI-Scripte sein, die BASH per

#!/bin/bash

direkt aufrufen, oder deren "/bin/sh" ein Link auf "/bin/bash" ist. In diesem Fall wären auch sämtliche system() un popen() Aufrufe der C-Library betroffen.

Was kann man dagegen unternehmen?

1.) Sofern möglich, sollte daher "/bin/sh" auf eine alternative Shell verweisen (bei Debian ist das seit einer Weile "dash").

2.) CGI-Scripts die bisher BASH nutzen laufen wahrscheinlich auch in einer anderen Shell. Ich hatte in der Vergangenheit z.B. Probleme bei der Migration von Scripten, die das BASH Kommando "let" verwendeten:

# in BASH
let T=1
let T=T+1

# in jeder Shell (auch BASH)
T=1
T=$((T+1))

3.) Schließlich kann man die Zeichenkette "()" in der HTTP-Kommunikation Filtern. Mir ist keine Anwendung bekannt, wo der String vorkommen würde. Im Fall von Apache sieht das so aus:

<Directory "/usr/lib/cgi-bin">
        SetEnvIf . "\(\)" shellshock
        AllowOverride None
        Options ExecCGI
        Order allow,deny
        Deny from env=shellshock
        Allow from all
</Directory>

Update (2014-10-26)

OK, evtl. war ich etwas voreilig mit meiner Einschätzung... es gibt wohl noch weitere Software, die einen Teil des Inputs auf irgendeine Weise an eine Shell übergeben könnte. Neuerdings gibt es einen Exploit für Postfix. Natürlich haben wir schon längst die gepatchten Versionen von BASH eingespielt - aber man weiß ja nie...
Postfix könnte durchaus eine Mail an einen Prozess weiterleiten, der eine BASH  aufruft (Spam/Virus Filter, Abwesenheitsnotiz oder ein Statistikscript). Damit könnten auch Benutzerrechte außerhalb des Mailservers erreicht werden.

Better save than sorry, mit Postfix gestaltet sich eine Filterung noch vor der Mail-Annahme recht einfach. So halten wir auch Systeme sauber, an die wir Mails übermitteln.

#/etc/postfix/main.cf

header_checks = pcre:/etc/postfix/header_checks

#/etc/postfix/header_checks

/\(.*\).*\{.*;/         REJECT  ShellShock Suspect

Alternativ könnte man den Header auch entfernen oder den betreffenden Text ersetzen.

Wahrscheinlich wird Postfix nicht das letzte Programm sein, ich könnte mirvorstellen, dass Asterisk mit seiner AGI-Schnittstelle ebenfalls ein lohnendes Ziel darstellt - falls AGI die Header ebenfalls zum Setzen von Umgebungsvariablen heranzieht.