Exim, Qmail und Procmail-Installationen anfällig für Shellshock-Attacken
Der vor einigen Wochen aufgetretene "Shellshock"-Bug zieht weitere Kreise. Neueste Erkenntnisse zeigen: Mailserver mit Exim und QMail sind anfällig. Normale Postfix-Mailserver sind es nicht. Aber: Der Local Delivery Agent "Procmail" ist anfällig (egal ob unter Exim, Qmail oder Postfix). Und auf Debian- und Ubuntu-Systemen kommt Procmail per Default ungefragt zum Einsatz. Mittels speziell präparierter E-Mails könnte auf diesem Weg von außen Code auf die Systeme eingeschleust und ausgeführt werden. Nochmal: Normale Postfix-Systeme ohne procmail gelten als nicht gefährdet, hier macht sich die saubere Programmierung und konsequent sichere Programmierung von Postfix bezahlt. Aber: Werden Mails durch "Procmail" verarbeitet könnten Mailserver anfällig sein.
Procmail kommt bei Debian/Ubuntu standardmäßig zum Einsatz
Und leider: Auf jedem Debian-/Ubuntu-System in Postfix das $mailbox_command auf procmail verbogen und damit der (sichere) Postfix-eigene MDA "local" ersetzt. Das Kommando "postconf mailbox_command" zeigt das schnell:
root@host:~# postconf mailbox_command mailbox_command = procmail -a "$EXTENSION"
Auf normalen Postfix-Systemen mit reiner Standard-Konfiguration (SUSE, RedHat u.a.) ist $mailbox_command hingegen leer:
root@host:~# postconf mailbox_command mailbox_command =
Systeme, die die speziellen Filtermechanismen von Procmail nicht einsetzen, sollten (sowieso) auf Procmail verzichten und den entsprechenden $mailbox_command-Eintrag in der main.cf verzichten.
Auch Nicht-Mailserver können gefährdet sein
Auch Debian-/Ubuntu-Systeme die nicht als Mailserver eingesetzt werden könnten gefährdet sein, schließlich könnten externe Angreifer auch Mails an root@$myhostname adressieren und dadurch Mails durch Procmail leiten. Doch nicht jede Procmail-Installation ist automatisch angreifbar -- entscheidend ist, ob im Rahmen der Procmail-Filterung Teile aus Mailheadern in Shell-Enviroment-Variablen ausgelagert und verarbeitet werden und so den ShellSchock-Bug auslösen lönnten. Wer Procmail zur Mailfilterung benötigt und gezielt dafür einsetzt, sollte sein Regelwerk auf die unsichere Verarbeitung von Mailheadern überprüfen. So oder so steht an allererster Stelle aber weiterhin das Einspielen der Security-Updates der bash, die den Shellschock schließen sollen. Denn der eigentliche Shellschock-Bug ist mittlerweile über einen Monat alt... Wir danken Markus Manzke von Mare Systems für unsere gemeinsame Sicherheits-Kooperation.
Weitere Beiträge zum Thema
Enterprise Mail Security with Open Source?
SMTP smuggling aka Postmasters Weihnachtsstress
Kommentare
7 Antworten zu Exim, Qmail und Procmail-Installationen anfällig für Shellshock-Attacken
Bei meiner openSUSE 13.1 habe ich:
<code>
# rpm -e procmail
error: Failed dependencies:
procmail is needed by (installed) sysstat-10.1.5-18.1.x86_64
procmail is needed by (installed) rbme-1.6-9.21.noarch
/usr/bin/procmail is needed by (installed) jailkit-2.13-1.7.x86_64
</code>
Also stimmt es zwar, dass Procmail nicht von Postfix gebraucht wird, aber es ist wegen anderer Abhängigkeiten installiert.
Gruß
Werner
Installiert kann es ja sein; solange es nicht aufgerufen wird ist doch alles trotzdem in Ordnung.
Danke für diese ausführliche Beschreibung der Lücke und ihrer Angriffsvektoren.
Die bekannten Newsseiten sparen leider mit detaillierten Informationen.
Mit bestem Gruß,
John
Hier ein Beispiel, wie so eine Mail aussehen kann:
http://blog.svenmielke.eu/shellschock-per-mail/
https://twitter.com/cebe_cc/status/526728589468000256
Seid ihr sicher das procmail wirklich standard bei Debian/Ubuntu ist?
Habe mehrere System mit Debian wheezy und squeeze getestet sowie ein Ubuntu 14.04 und überall ist "postconf mailbox_command" leer ... .
Das liegt etwas daran, wie man beim Installer die Start-Config von Postfix erzeugt. Da kann man ja einen Anwendungszweck für den Postfix angeben.
Hallo Peer,
nein Qmail und s/qmail sind nicht anfällig für das Problem 'SMTP Smuggling'; zumindest nicht in der 'vanilla' Version.
Kann darüber gerne berichten.
--eh.