Sicherheitslücke in Bash

[bisty]

Hallo, Admins, man hat vor kurzem eine ziemlich interessante Sicherheitslücke in Bash gefunden, die man auch per Netzwerk ausnutzen kann. Ich würde also an eure Stelle Bash updaten, falls ihr das noch nicht gemacht habt, und falls das nicht automatisch gemacht wurde.

[Evenprime]

Der Server ist seit heute Morgen auf aktuellem Stand. Ich hoffe mal, dass der letzte Bugfix nun auch tatsächlich hält.

Für uns hier sollte es zumindest nach aktuell bekannten Informationen nicht (so) gefährlich gewesen sein wie für andere Server, da die imho gefährlichste Angriffsfläche über Apache in Kombination mit cgi-scripts bei uns in der Form (afaik) nicht vorkommt.

Trotzdem natürlich better safe than sorry und jedenfalls Danke für den Hinweis.

[Dai Senpai]

Bestes Techmin Team EU West! ^^
Even is best Jungle-Champ EU West... nerf pls

Sauber hinbekommen. Mal ne Frage, was wäre passiert wenn diese Sicherheitslücke gegriffen hätte?

[Evenprime]

(27.09.2014)Die4Ever schrieb:  Bestes Techmin Team EU West! ^^
Even is best Jungle-Champ EU West... nerf pls

Sauber hinbekommen. Mal ne Frage, was wäre passiert wenn diese Sicherheitslücke gegriffen hätte?

Ich verstehe kein Wort.

Also ich versuche mal zu erklären, was die Sicherheitslücke bedeutet (für nicht-Techniker):

Unter bestimmten Umständen war es möglich mit einem normalen Aufruf einer Webseite (z.b. "http://www.google.com") am Server beliebigen Code auszuführen mit den Rechten der Webserveranwendung (welche zumindest in den für die Webseite relevanten Verzeichnissen Lese- und meist Schreibrechte hat). Also es wäre ohne weiteres möglich auf verwundbaren Webseiten Dateien direkt von der Festplatte des Servers zu löschen oder diese zu verändern. Auch das Installieren von neuen Programmen wäre meist kein Problem.

Die "bestimmten Umstände" sind recht häufig im Internet zu finden: Die Webseite muss den Apache Webserver (oä.) nutzen und während dem Verarbeiten der Anfrage zu irgendeinem Zeitpunkt ein Shell-Skript ausführen (egal welches, hauptsache es wird mit Hilfe der "Bash" ausgeführt, was auf den meisten Linux/Unix/MacOS-Systemen wohl der Fall ist).

Die reine Standard-MyBBoard-Software macht keine solchen Aufrufe (soweit mir bekannt), da sie diese nicht benötigt und somit leichter auch auf billigen Webhostern (die entsprechende Skripte nicht oder nur gegen Aufpreis unterstützen) installierbar ist.

Aber für komplexere Webanwendungen kann man auf die Möglichkeit Shell-Skripts auszuführen nicht verzichten und auch vorallem Geräte die über eine Weboberfläche gesteuert werden können (z.B. Router/Modems bei den Leuten zuhause) brauchen diese Möglichkeit, um zu funktionieren.

Es sind auch noch ein paar andere Dinge betroffen, jenseits von Webservern, aber das ist das einzige was für uns hier mMn. im Moment relevant gewesen wäre.

[Dai Senpai]

Ahhh, danke für diese Erklärung. Nun blicke ich da ein bisschen besser durch! ^^

Gottseidank habt ihr das dann gefixed! ^^; Gute Arbeit.

[mrx1983]

Ich werde nix fixen ^^
Dafür habe ich Marcell Davis
Ne aber ich habe auch mal bei 1&1 angefragt wie das aussieht mit der Bash Sicherheitslücke
Mal hoffen das deren Server davon jetzt nicht zu stark betroffen sind und es schnell gefixt wird.

[Herrmannsegerman]

Muss mich denn als Otto-Normal Internetnutzer jetzt irgendwas beachten?

[mrx1983]

(27.09.2014)Herrmannsegerman schrieb:  Muss mich denn als Otto-Normal Internetnutzer jetzt irgendwas beachten?

Also wenn du Linux mit Bash am laufen hast und eine Applikation wie einen Webdienst nach außen hast, könnte was passieren.
Ich denke das betrifft vorallem Webserver.
Od. auch Geräte auf Linux Basis die Bash am laufen haben, und Dienste nach außen haben

[Herrmannsegerman]

(27.09.2014)mrx1983 schrieb:  

(27.09.2014)Herrmannsegerman schrieb:  Muss mich denn als Otto-Normal Internetnutzer jetzt irgendwas beachten?

Also wenn du Linux mit Bash am laufen hast und eine Applikation wie einen Webdienst nach außen hast, könnte was passieren.
Ich denke das betrifft vorallem Webserver.
Od. auch Geräte auf Linux Basis die Bash am laufen haben, und Dienste nach außen haben

Nah, dann nicht. Mit Linux hab ich nichts am Hut. Thanks for se Help.

[Lappen]

Ziemliche Panikmache mal wieder. Wer Software am laufen hat, bei der sich das überhaupt ausnutzen lässt, der hat das eigentliche Problem schon gefunden.

[404compliant]

Der Fehler kann wirklich nur zuschlagen, wenn irgendwo vom Webserver aus Shell-Skripte gestartet werden, was eigentlich an sich schon ein Anachronismus und eine Performace-Krücke ist. Zusätzlich müssen diesem Shell-Skript noch ungeprüft Environment-Variablen übergeben werden, was auch... naja ist. Und selbst dann, läuft solcher eingeschleuster Code in der Regel maximal mit sehr eingeschränkten Rechten.

Normale Standard-Szenarien, z.B. LAMP-Webserver o.ä. laden z.B. die PHP-Skripte direkt per Modul in den Webserver, ohne Umwege. So lange diese PHP-Skripte dann nicht externe Programme über bash-Umweg starten und auch noch ungeprüft Müll in die Environmnt schreiben (was sicher noch einige andere, interessante Risiken birgt), kann nichts passieren.

[Evenprime]

(29.09.2014)404compliant schrieb:  So lange diese PHP-Skripte dann nicht externe Programme über bash-Umweg starten und auch noch ungeprüft Müll in die Environmnt schreiben (was sicher noch einige andere, interessante Risiken birgt), kann nichts passieren.

Offenbar ist genau das das Problem, denn zumindest soweit ich es laut Beschreibung in den Veröffentlichungen zu dem Bug rauslesen konnte, gibt der Apache immer ein paar Environment-Variablen per Default an die Skripte mit. Unter anderem den "Host"-Wert aus dem Request des Besuchers, der vom Besucher bzw. dessen Browser anhand der aufgerufenen url festgelegt wird und daher auch beliebig manipuliert werden könnte.

Kann auch sein, dass ich den Teil missverstanden habe, daher bitte nicht auf mich berufen.

[404compliant]

Beim alten CGI-BIN Interface, ja. Aber wie schon gesagt, so hat man Webinhalte vor 20 Jahren produziert. Allein der Overhead, für jeden Seitenabruf mindestens einen (eher mehr) Unix-Prozesse zu starten, ist hoffnungsloser Overkill.

Lässt man mal CGI-BIN außen vor, bleiben eventuell von direkt im Webserver laufenden Skripten angestoßene Programme. Zum Beispiel Tools wie ImageMagick, um Bilder zu skalieren, oder ähnliches. In dem Fall würde man aber direkt das Tool starten, statt den Umweg über die bash zu gehen. Und außerdem kommt da hoffentlich keiner auf die Idee, Parameter per Environment statt schlicht als Parameter zu übergeben.

Jeder Versuch, hier Dinge mittels Shell-Skripten zu lösen, führt direkt in eine Hölle, gegen die SQL-Injection harmlos sind. Nebenbei angemerkt, die AVM FritzBox-Lücke von Anfang des Jahres fällt in diese Kategorie, auch da wurde Shellscript-Code über den Umweg einer Environment-Variable durch den Webserver geschleust und versehentlich von einem Skript ausgeführt. Gerade bei embedded Systemen wird gerne der Webserver eng mit dem Unix-Kern verbunden, weil es Mehraufwand vermeidet.