Ich wundere mich, dass ein SUID-Programm wie passwd verwendet die setuid() Funktionsaufruf. Warum werden Root-Rechte gelöscht?
Gegen welche Arten von Angriffen hilft das? Pufferüberlauf?
Akzeptierte Antwort:
Zuerst werde ich das Setuid-Bit besprechen, das passwd verwendet und sich von setuid() unterscheidet Systemaufruf (den passwd nicht verwendet). In dieser Hinsicht gibt es vielleicht einige Verwirrung in der Frage.
Es ist kein Schutz vor einem Pufferüberlauf, es ist angreifbar zu solchen oder im Grunde alles, was einem Angreifer erlauben würde, einen privilegierten Prozess für einen schändlichen, unbeabsichtigten Zweck zu verwenden. Das liegt daran, dass das setuid-Bit das Gegenteil von „Privilegien löschen“ ist; es verleiht Root-Rechte, aber nur für den Prozess und nicht der eigentliche Benutzer. Dazu gehört passwd .
Diese Form von setuid erfordert, dass das setuid-Bit des Dateisystems auf der ausführbaren Datei gesetzt ist; passwd hat dies, weil es Berechtigungen zum Lesen und Schreiben von /etc/passwd benötigt . Wir hoffen jedoch, dass passwd keine bekannten Sicherheitslücken hat (z. B. potenzieller Überlauf-Exploit), die es einer schändlichen Person ermöglichen würden, etwas anderes zu tun, als /etc/passwd zu lesen und zu schreiben (und das nicht richtig zu tun!), da es läuft als root und könnte es daher alles tun – außer es ist nur für eine bestimmte Sache konzipiert und es dazu zu bringen, etwas anderes zu tun sollte (wieder hoffentlich) unmöglich sein.
Die Verwendung von setuid in diesem Sinne ist also kein Schutz vor irgendetwas , wird aber oft im Zusammenhang mit Sicherheitslücken diskutiert, da potenzielle Sicherheitslücken sehr wichtige ausführbare WRT-Setuid-Dateien sind.
ABER:das setuid-Bit setzt die euid und nicht die tatsächliche uid, also ist es tatsächlich parallel zu seteuid() Systemaufruf und nicht setuid() .
Es gibt eine entgegengesetzte Form von „setuid“, bei der es darum geht, Privilegien zu löschen, was die eigentliche setuid() beinhaltet Systemaufruf und erfordert kein setuid-Bit. Dies ist der Fall, wenn ein Prozess, der als Root ausgeführt wird (weil Root oder sudo ihn gestartet haben), seine UID auf einen weniger privilegierten Benutzer ändert. Server und Daemons tun dies oft, wenn sie Root-Rechte beim Start benötigen (z. B. um einen privilegierten Port zu öffnen), aber nicht danach. Wenn der Server anschließend gejackt wird, hat er auf diese Weise keine Superuser-Privilegien. Sie können setuid(0) nicht aufrufen und erhalten Sie die Root-Rechte zurück (aber Sie können mit set*e *uid).