Bundesamt für Sicherheit in der Informationstechnik

M 5.19 Einsatz der Sicherheitsmechanismen von sendmail

Verantwortlich für Initiierung: Administrator

Verantwortlich für Umsetzung: Administrator

Da die Übertragung von Mails die wohl am meisten verbreitete Anwendung in Netzen ist, sind die dafür zuständigen Prozesse von besonderer Bedeutung und einer der häufigsten Angriffspunkte in einem System. Hinzu kommt, dass diese Prozesse häufig das suid-Bit gesetzt haben und einem privilegierten Benutzer gehören (z. B. root oder bin). Ein Fehler in sendmail war z. B. einer der Wege, über die sich der Internet-Wurm ausgebreitet hat.

  • Beim Starten von sendmail lassen sich sehr viele Optionen angeben, die zu Sicherheitsproblemen führen würden, wenn sie mit root-Rechten abliefen. Wenn sendmail von beliebigen Benutzern aufgerufen werden kann, sollte deshalb überprüft werden, ob es beim Start mit einer dieser Optionen das gesetzte suid-Bit ignoriert und mit der UID des Benutzers abläuft. Um Sicherheitsprobleme zu vermeiden, sollte der Administrator sicherstellen, dass sendmail nur mit den folgenden Optionen bei gesetztem suid-root-Bit von unprivilegierten Benutzern gestartet werden kann: 7, b, C, d, e, E, i, j, L, m, o, p, r, s und v.
  • Aufgrund der in der Vergangenheit aufgedeckten Sicherheitsdefizite des Programms sendmail muss stets die aktuellste Programmversion eingesetzt werden. Informationen über die aktuellen Versionen erteilen die in M 2.35 Informationsbeschaffung über Sicherheitslücken des Systems angegebenen Stellen wie BSI , CERT , DFN-CERT.
  • Der sendmail-Prozess darf nicht im Debug-Modus betrieben werden können, da es sonst möglich wird, root-Rechte zu erlangen. Man kann dies testen, indem man den Befehl
    telnet localhost 25
    eingibt, wobei localhost der zu überprüfende Rechnername sein kann und 25 die Portnummer, mit der der sendmail-Prozess angesprochen wird. Der Rechner bzw. der sendmail-Prozess meldet sich dann mit
    Trying 123.45.67.8...
    Connected to xxx.yy.de.
    Escape character is '^]'.
    220 xxx Sendmail 4.1/SMI-4.1 ready at Wed, 13 Apr 94 10:04:43 +0200

    Wenn Sie nun den Befehl debug, showq oder bei sehr alten Versionen wizard eingeben, sollte dies der Prozess mit
    500 Command unrecognized
    ablehnen. Die Verbindung kann mit dem Befehl quit wieder beendet werden.
  • Die Befehle vrfy und expn dürfen nicht verfügbar sein, da sie zu einem Mailnamen den zugehörigen Login-Namen ausgeben, so dass sich dann durch Probieren evtl. das zugehörige Passwort herausfinden lässt. Bei Version 8 von sendmail lassen sich diese Befehle z. B. durch die Option p (privacy) beim Starten abschalten. Ob diese Befehle verfügbar sind, lässt sich wie im vorigen Punkt beschrieben feststellen, also z. B. durch Eingabe des Befehl vrfy useralias.
  • Die Konfigurationsdatei sendmail.cf sollte root gehören und auch nur für root les- und schreibbar sein. Dasselbe gilt für die darüber stehenden Verzeichnisse, da sich sonst durch ein einfaches Umbenennen dieser Verzeichnisse eine neue sendmail.cf Datei erzeugen lässt.
  • Die Angabe von ausführbaren Programmen oder von Dateien als gültige Adressen für Empfänger oder Absender muss durch die Konfiguration von sendmail.cf verhindert werden oder durch geeignete Maßnahmen auf bestimmte, unbedenkliche Programme und Dateien eingeschränkt werden.
  • Das F-Kommando (also z. B. FX/path [^#]), mit dessen Hilfe Klassen definiert werden, sollte in der Konfigurationsdatei (sendmail.cf) nur benutzt werden, um Dateien zu lesen, die systemweit lesbar sind, da es sonst möglich sein kann, dass sicherheitsrelevante Informationen aus geschützten Dateien frei verfügbar werden. Die Programmform des F-Kommandos (z. B. FX|/tmp/prg) sollte nicht benutzt werden!
  • Bei der Definition des Delivery Agents (z. B. Mlocal) dürfen nur absolute Pfade angegeben werden (z. B. P=/bin/mail). Außerdem sollte das Flag S (suid) nur gesetzt werden, wenn die damit evtl. verbundenen Sicherheitsprobleme geklärt sind.
  • Jede Datei, in die sendmail schreiben könnte, wie z. B. sendmail.st für eine Statistik, sollte nur von root beschreibbar sein und auch nur in root gehörenden Verzeichnissen stehen. Dasselbe gilt für Dateien, die von sendmail ausgewertet werden wie z. B. :include: in Mailing Listen.
  • Privilegierte Benutzer wie bin oder root sollten keine .forward Datei besitzen. Sind nämlich die Benutzer- oder Gruppenschreibrechte für diese Datei falsch gesetzt oder gelingt es einem Benutzer, in eine privilegierte Gruppe zu gelangen, kann er sich eine Shell mit der privilegierten Benutzer-Kennung erzeugen.
    Für normale Benutzer sollte die .forward-Datei nur von dem Besitzer beschreibbar sein und muss sich in einem Verzeichnis befinden, das dem Besitzer gehört.
    Falls ein Heimatverzeichnis systemweit beschreibbar sein muss, wie z. B. uucp, lässt sich auf folgende Weise verhindern, dass eine schädliche .forward-Datei angelegt werden kann: Es muss ein Verzeichnis mit dem Namen .forward, den Rechten 000 und dem Besitzer root angelegt werden und in diesem eine Datei ebenfalls mit den Rechten 000 und dem Besitzer root, so dass niemand außer root diese Datei verändern oder löschen kann. Das Homedirectory von uucp sollte dann ebenfalls root gehören und mit dem Sticky-Bit (t) versehen sein. Eine analoge Vorgehensweise empfiehlt sich auch für andere Konfigurationsdateien (z. B. .login, .cshrc) in systemweit beschreibbaren Verzeichnissen.
  • Aus der Alias-Datei sollte jedes ausführbare Programm entfernt werden, insbesondere auch uudecode. Außerdem sollte die Alias-Datei und die zugehörige Datenbank root gehören und auch nur für root beschreibbar sein.
  • Es muss beachtet werden, dass jede empfangene Mail verfälscht sein kann. Dies kann entweder in der Mailqueue geschehen oder durch ein Einloggen auf Port 25. Ersteres lässt sich vermeiden, wenn das Mailqueue-Verzeichnis root gehört und die Rechte 0700 besitzt. Die Queue-Dateien sollten die Berechtigung 0600 haben. Die Veränderung einer Mail während ihres Transportes lässt sich nicht vermeiden, so dass die Benutzer darüber aufgeklärt werden müssen, dass z. B. eine Mail von root, in der sie dazu aufgefordert werden, ihr Passwort zu ändern, gefälscht sein kann.

Prüffragen:

  • Wird sichergestellt, dass sendmail bei gesetztem suid-root-Bit nur mit zulässigen Optionen gestartet werden kann?

  • Wird der Betrieb des sendmail-Prozesses im Debug-Modus verhindert?

  • Wird die Ausführung der Befehle VRFY und EXPN bei sendmail verhindert?

  • Sind die Berechtigungen für relevante Dateien ( z. B. sendmail.cf, sendmail.st, alias, queue, :include: in Mailing Listen) und die darüber stehenden Verzeichnisse auf ein notwendiges Maß reduziert?

  • Werden bei der Definition des Delivery Agents ( z. B. Mlocal) nur absolute Pfade angegeben ( z. B. P=/bin/mail)?

  • Existieren die forward-Dateien exklusiv nur für unprivilegierte Benutzer?

Stand: 13. EL Stand 2013