Durch eine fehlerhafte Auswertung von Umgebungsvariablen, kann ein lokaler Angreifer beliebigen Code als Root ausführen.

Wichtig sind zwei Parameter:

A) Er muß die Umgebungsvariablen beeinflussen aka. setzen können.

B) Er muß ein Programm starten können, daß Root gehört und das „+s“ (SetUID) Flag hat.

Mehr Infos Link: http://seclists.org/oss-sec/2016/q3/617

Wer ist betroffen ?

Betroffen ist u.a. die gesamte Fedora Palette:

Red Hat Fedora 23
Red Hat Fedora 24
Red Hat Fedora 25

Es dürften aber alle, die Bash < 4.4 einsetzen von dem Problem betroffen sein und betrifft wohl jeden Desktopnutzer.

Warum melde ich das heute, ist doch nur eine Sicherheitslücke unter vielen ?

Ohne Bashing betreiben zu wollen, aber im OSBN tauchte heute folgender Beitrag auf :  Defektes Piwik nach Update auf 2.16.3

Kurzfassung: Weil Piwik (Webanalysesoftware wie Google Analytics) plötzlich nach einem Update  500er Fehler geworfen hat, entfernte der Serverbetreiber einfach Kurzerhand die paar Restsicherheitsmaßnahmen des Apachewebservers und erlaubte es dem Piwik unnötige und sehr gefährliche Apache-Directiven in der .htaccess  auszuführen. (Wie ich grade gesehen habe, ist mein Protest auf fruchtbaren Boden gefallen und er hat es korregiert 😀 )

Hintergrund des Protestes ist, daß mit der Anweisung „AllowOverride All“ in einer Htaccess auch AddHandler und Action Anweisungen erlaubt sind.  Mit denen kann u.a. das machen :

AddHandler php-script .php .pl .rb .py .exe .cgi .sh 
Action php-script /cgi-sys/cgiwrap

Mit „/cgi-sys/cgiwrap“, was ein CGIWrapper wie FastCGI oder ein Eigenbau wie bei uns sein kann, sorgt der Webserverbetreiber normalerweise dafür, daß Prozesse als User und in einer Chroot ausgeführt werden, statt als Apachebenutzer und mit Zugriff auf “ / „. Kann ich die Optionen als Angreifer frei setzen, kann ich eigene Kommandos statt des Cgiwrappers ausführen und damit auch außerhalb der Chrootumgebung. ( Klar das Ausführen von Programmen geht beim Webangriff auch anders, gehen wir mal davon aus, daß das der einzige Weg wäre).

Wenn ich eigene Kommandos ausführen kann, kann ich obige Schwachstelle ausnutzen und Root werden. Da die obige Schwachstelle der Bash darauf beruht, daß man eine SETUID Programm ausführen muß und in einer CHROOT keine SetUID Programme von Root sind, weil es keinen Root User gibt(der ist da prinzipbedingt unnötig), kann man trotz verwundbarer Version von Bash, den Angriff nicht durchführen.  Kann ich aber den Wrapper umgehen und im Realsystem arbeiten, finde ich auch Root-SetUID Programme und der Hack gelingt.

Und deswegen trägt man in seinen Vhost das hier ein : „AllowOverride AuthConfig Indexes Limit FileInfo“ und nichts anderes.

So tragen verschiedene Mechanismen dazu bei, daß ansonsten verwundbare Systeme doch nicht geknackt werden. Die Bash braucht man oft auch in der Chroot, außer man hat keine generelle Hostingumgebung, sondern läßt da genau eine Sache drin ablaufen, was auch legitim wäre.