chmod/chown gingen nur für einen bestimmten Ordner, /foo.

Die Bash macht kein setuid(), d.h. sie hätte auch keine Rootshell ergeben, selbst wenn man ihr das SetUID-Bit gibt.

Vereinfacht: es sollte dazu dienen, dass ein User, der Dateien hochlädt, deren Rechte mit seinem Shelluser anpassen darf, sodass auch der Webserver Rechte auf die Dateien hat (oder halt nicht).

In dem Fall war die Intention anscheinend einem einfachen Nutzer nur Chown/Chmod zu erlauben, aber man hat ihm stattdessen versehentlich die Möglichkeit gegeben eine Root-Shell zu öffnen.

Naja, sudo war auf die Befehle chmod und chown beschränkt und hätte dem Benutzer selbst direkt gar keine root-Shell ermöglicht.

Doch, na klar… dann darf man hat das setuid-Bit setzen und den Besitzer auf root ändern, z.B. auf /bin/bash und schon hat man eine root-Shell und darf den ganzen anderen Rest auch.

Oder die Zugriffsrechte auf /dev/mem ändern und den Speicher vollmüllen und und… wenn man jemanden sudo-Recht auf chown und chmod gibt, dann gibt man demjenigen alle Rechte. Aber das sollte eigentlich jedem klar sein. Das ist keine Sicherheitslücke, sondern funktioniert so, wie es soll.

Stefan, kannst Du vielleicht noch kurz etwas zum Hintergrund sagen, wieso der Admin den Usern chmod/chown erlauben wollte? Was hatte er sich dabei gedacht? Wenn man das weiß, kann man auch überlegen, wie er es hätte besser machen können. Was diesem Beitrag inhaltlich noch ein Tüpfelchen verpassen würde.

Erklär mal, was genau daran der Hack sein soll. Danke!

Horst

Ansonsten leider ein ziemlich typisches Szenario.