Aktuelle Sicherheitslücken

Zitat von COLOSSUS

Ich bin extra zum Patchen frueher vom Einkaufen heim gestern, nachdem ich in der Warteschlange an der Kasse wie ueblich Hackernews gelesen hatte - mein blog ist ein bash-Script via mod_cgi

Der btw grad einen 500 Error schmeisst

Zitat von Smut

mehr sorgen machen mir derzeit appliances udgl. da wird wohl erst im laufe der nächsten woche etwas kommen.

Sophos schrieb zu dem Thema vor ein paar Stunden auf ihrem Blog

Zitat

In the light of the recent Bash vulnerability, Sophos has reviewed all of our products to understand if any are at risk from the vulnerability. We can confirm that none – including Sophos Email Appliance, Sophos Web Appliance, PureMessage for Exchange and SAV for Linux – are vulnerable. The main user-facing components of Sophos UTM...

In der Zwischenzeit ist der Blogeintrag wieder verschwunden... Was immer das auch heissen mag...

Auf ihrer UTM läuft zumindest Version 3.2.51(1), welche verwundbar ist. Wer jedoch auf ner Sophos die SSH Konsole ohne Limitierung ins Internet rausführt, dem ist eh nicht mehr zu helfen... Von daher gehe ich zur Zeit davon aus, dass dieser Shellshock für Sophos halb so wild ist...

By the way, das Skript um die Verwundbarkeit zu testen der Vollständigkeit halber:

Code:

env X="() { :;} ; echo busted" /bin/sh -c "echo completed"
env X="() { :;} ; echo busted" `which bash` -c "echo completed"

Debian hat den fix für 7169 als erster:
https://lists.debian.org/debian-sec...4/msg00223.html

auchtung, der heise beitrag ist von gestern und war selbst zu dieser uhrzeit leider schon 8 stunden hinten nach.
der erste patch: cve-6271 -> war incomplete
der zweite patch (heute nacht released: cve: 7169 ist derzeit noch nicht für alle distributionen verfügbar. für RHEL/Centos gibt es ihn mittlerweile auch, wenn auch noch nicht auf allen repo mirrors.

ah ok. ich war verwirrt, da die links auf cve 6271 zeigen.

@GTA: Nein, das verstehst du falsch. Ich kann jetzt auf die schnelle in der APR den Code zum Zitieren nicht auffinden, aber das laeuft so: nachdem der Apache httpd Request Handler entschieden hat, dass Request X mit Handler Y via mod_cgi und CGI-Script Z ausgefuehrt werden soll, legt httpd bestimmte Request-(Meta)Daten in seinem Environment ab und forkt ein Child, vermutlich via execve(3), um in diesem Child Z auszufuehren. Wenn das CGI-Script Z nun ein Textfile mit executable-Bit ist, prueft daraufhin _der Kernel_, ob das File mit der magischen Anfangssequenz "shebang" ("#!") beginnt, und fuehrt dann (ueber einen relativ grauslichen Hack incl. Race Condition...) den Text der ausfuehrbaren Datei dem stdin des hinter dem shebang notierten Interpreters zu. Bis hierher ist erstmal keine Shell involviert - aber ab hier _kann_ sie es sein, wenn es sich eben um ein echtes Shellscript handelt. Ist der Interpreter aber nicht bash, und fuehrt dieser niemals als Kindprozess (mit dem Environment, das er von httpd geerbt hat) die bash aus, bist du "sicher" vor dem Exploit, da andere Programme/Interpreter als bash ja nicht allergisch auf diese Art der Environment-"Vergiftung" reagieren.

dieser patchday ist heiß
http://m.heise.de/newsticker/meldun...ln-2452043.html