Mittwoch, 17. März 2010, 17:21
Sicherheitslücke in SpamAssassin-Filtermodul
Betrifft uns zwar nicht:
Sicherheitslücke in SpamAssassin-Filtermodul
ist aber böse, wenn man sich einmal den Code anschaut:
Meine ganz persönliche Meinung: System-Aufrufe (egal in welcher Programmiersprache) sollten grundsätzlich nicht zulässig sondern nur unter ganz bestimmten Voraussetzungen explizit erlaubt sein.
Sicherheitslücke in SpamAssassin-Filtermodul
ist aber böse, wenn man sich einmal den Code anschaut:
sfsistatKein Wunder, dass dann soetwas Simples wie
mlfi_envrcpt(SMFICTX* ctx, char** envrcpt)
{
// gekürzt
char buf[1024];
char *fmt="%s -bv \"%s\" 2>&1";
// gekürzt
snprintf(buf, sizeof(buf)-1, fmt, SENDMAIL, envrcpt[0]);
// gekürzt
p = popen(buf, "r"); [1]
// gekürzt
}
RCPT TO: root+:"|touch /tmp/foo"zu einer Sicherheitslücke führt.
Meine ganz persönliche Meinung: System-Aufrufe (egal in welcher Programmiersprache) sollten grundsätzlich nicht zulässig sondern nur unter ganz bestimmten Voraussetzungen explizit erlaubt sein.
Kommentare
Ansicht der Kommentare: Linear | Verschachtelt
rae
http://www.hornoxe.com/wp-content/picdumps/picdump144/hornoxe.com_picdump144_049.jpg
Dieser wiederum verführte mich zu dem Statement, dass jegliches Werkzeug, mit dem man Quelltext editieren kann, mit einer Zwangsaktivierung versehen werden sollte. Und der Aktivierungsschlüssel lautet "TRAUE KEINEM INPUT!" in 100facher Wiederholung.
Dirk
Ein Besserwisser schrieb
Sendmail ist NICHT der Fehler. Sendmail weigert sich sogar, die Pipe zu akzeptieren.
Postfix ist NICHT das Problem, da normalerweise Mails ohne Domain-Part abgewiesen werden.
Verwundbar sind nur die Postmaster, die ihre Server so seltsam konfigurieren, dass sie unter dem root-Account laufen und/oder zumindest deren Plug-Ins. Darüber hinaus muss man auch noch grobe Schnitzer in die Konfiguration einbauen, und erst dann ist eine solche Sicherheitslücke im Plug-In fatal.
Die Lücke an sich ist natürlich auch ein riesiges Problem, richtet im Alleingang allerdings nicht viel Schaden an. In Kombination mit Sicherheitslücken anderer Software auf dem Server kann es sich aber schnell zu einem echten Problem hochschaukeln.
Ryukia
Tux2000
... und schon stirbt der (Perl-)Prozess, der es wagt, unverifizierten Input an kritische Funktionen wie system(), exec() oder auch als Format-String an printf() (ab 5.10) weiter zu reichen.
Mehr: http://perldoc.perl.org/perlsec.html
Generell halte ich Funktionen, die einen zusammengestrickten String an die Shell weiterreichen (wie eben system() und bei Perl auch die Varianten von open(), die popen() in C entsprechen) sicherheitsmäßig für eine extrem blöde Idee.
Tux2000
petschge
Exact den gleichen (konzeptionellen) Bug habe ich vor kurzen in einem PHP-Skript gesehen. Der schuldige Coder wusste nichtmal daß es Funktionsaufrufe gibt, bei denen man Programmname und Argumente sauber getrennt übergeben kann.
Kels