Direkt zum Inhalt
25.10.2014 - Fachbeitrag

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.  

Kommentare

7 Antworten zu Exim, Qmail und Procmail-Installationen anfällig für Shellshock-Attacken

w-Icon
Werner Flamme
26. October 2014 um 00:53

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

p-Icon
Peer Heinlein
26. October 2014 um 01:04

Installiert kann es ja sein; solange es nicht aufgerufen wird ist doch alles trotzdem in Ordnung.

j-Icon
John
27. October 2014 um 17:03

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

c-Icon
cebe
01. November 2014 um 03:54
s-Icon
Stefan
03. November 2014 um 22:59

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 ... .

p-Icon
Peer Heinlein
25. March 2015 um 08:13

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.

e-Icon
Erwin Hoffman
09. January 2024 um 22:21

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.