SELinux hilft (wenig) gegen Bash-Exploit Shellshock

26.09.2014

Der Red-Hat-Entwickler Dan Walsh hat analysiert, was passiert, wenn ein Apache-Server mit SELinux geschützt ist.

Dan "Mr. SELinux" Walsh von Red Hat hat genauer untersucht, welche Auswirkungen es hat, wenn die eben bekannt gewordene Bash-Sicherheitslücke ("Shellshock") auf einem System ausgenutzt wird, das von SELinux geschützt ist. Wie in einem Reddit-Post, auf den sich Walsh bezieht, zu sehen ist, verhindert SELinux nicht, dass ein Exploit auf dem angegrifenen System eine Datei anlegen kann, jedenfalls im Tmp-Verzeichnis. Dies liegt daran, dass die entsprechende SELinux-Policy genau dies erlaubt - schließlich müssen CGI-Skripts gelegentlich temporäre Dateien anlegen. Ohne SELinux könnte ein Bash-CGI-Exploit aber beispielsweise auch in Dateien schreiben, die Schreibrechte für den Webserver-Benutzer besitzen. Dies verhindert SELinux, indem es die Schreibrechte auf das Tmp-Verzeichnis begrenzt.

Ähnlich sieht es auch beim Lesen aus. Auch mit SELinux könnte ein Exploit eine Vielzahl von Dateien lesen, weil Prozesse mit dem Typ "httpd_sys_script_t" von Haus aus Zugriff auf viele Systemdateien und Verzeichnisse haben. Selbst die Passwort-Datei "/etc/passwd" wäre damit lesbar (allerdings nicht "/etc/shadow", das normalerweise nur mit Root-Rechten angesehen werden darf). Geschützt wären laut Walsh etwa die Home-Verzeichnisse mit dem SELinux-Typ "user_home_t", die aber ohnehin auf den meisten Linux-Systemen nur für den Benutzer selbst lesbar sind, und einige weitere Programme. 

Wie Walsh selbst einräumt, verschafft der SELinux-Schutz keinen umfassenden Schutz, kann aber immerhin die Auswirkungen einigermaßen eingrenzen. So verhindert SELinux durch seine Transition-Policy auch, dass Kindprozesse eines Exploits mit SUID-Rechten ausgeführt werden können.

Ähnliche Artikel

comments powered by Disqus
Mehr zum Thema

Bash-Lücke "Shellshock": Tests auf Verwundbarkeit und Abwehr

Die Sicherheitsprobleme mit der Bash-Shell haben sich ausgeweitet, doch es gibt keinen Grund zur Panik.

Artikel der Woche

Loadtests ohne Server

Für Loadtests der eigenen Server bietet sich die Cloud an, denn kurz getaktet lassen sich dort viele Rechnerinstanzen starten, die das eigene Budget nur wenig belasten. Noch flexibler, günstiger und besser skalierbar sind Tests mit einer Serverless-Infrastruktur wie AWS Lambda. Wir führen vor, wie Sie dort mit Serverless Artillery eigene Loadtests starten. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Container

Wie setzen Sie Container ein?

  • Gar nicht
  • Docker standalone
  • Docker mit Kubernetes
  • Docker mit Swarm
  • Docker mit anderem Management
  • LXC/LXD
  • Rocket
  • CRI-O auf Kubernetes
  • Container auf vSphere
  • Andere (siehe Kommentare auf der Ergebnisseite)

Google+

Ausgabe /2018

Microsite