%60%200%20zur%C3%BCckzugeben%2C%20ohne%20den%20Systemaufruf%20tats%C3%A4chlich%20durchzuf%C3%BChren%3F.png)
Ich habe die Dokumentation auf meinem Debian-System gelesen seccomp(2)
und bin über den folgenden Satz im folgenden Absatz gestolpert:
Ein solcher böswilliger Filter könnte beispielsweise dazu führen, dass bei einem Versuch,
setuid(2)
die Benutzer-IDs des Anrufers auf Werte ungleich Null zu setzen, stattdessen 0 zurückgegeben wird, ohne den Systemaufruf tatsächlich durchzuführen.
Wie können seccomp
Filter missbraucht werden, um das oben Beschriebene zu erreichen?
Wenn der bösartige Filter dies nicht zulässt setuid(2)
, erhält der Prozess wahrscheinlich ein SIGSYS
Signal und wird beendet, und der Systemaufruf wird nicht ausgeführt.
Wenn der Schadfilter dies zulässt setuid(2)
, execve(2)
ändert das Programm die UIDs des Benutzers korrekt.
Was vermisse ich?
man seccomp
:
...
Andernfalls schlägt die Operation SECCOMP_SET_MODE_FILTER fehl und gibt EACCES in errno zurück. Diese Anforderung stellt sicher, dass ein nicht privilegierter Prozess keinen bösartigen Filter anwenden und dann ein Set-User-ID oder ein anderes privilegiertes Programm mit aufrufen und
execve(2)
so dieses Programm potenziell kompromittieren kann. (Ein solcher bösartiger Filter könnte beispielsweise dazu führen, dass ein Versuch,setuid(2)
die Benutzer-IDs des Anrufers auf Werte ungleich Null zu setzen, stattdessen 0 zurückgibt, ohne den Systemaufruf tatsächlich durchzuführen. Auf diese Weise könnte das Programm dazu verleitet werden, Superuser-Privilegien beizubehalten, unter Umständen, in denen es möglich ist, es zu gefährlichen Dingen zu verleiten, weil es die Privilegien nicht tatsächlich aufgegeben hat.)...