Wie kann ein böswilliger Seccomp-Filter einen Versuch auslösen, mit `setuid(2)` 0 zurückzugeben, ohne den Systemaufruf tatsächlich durchzuführen?

Wie kann ein böswilliger Seccomp-Filter einen Versuch auslösen, mit `setuid(2)` 0 zurückzugeben, ohne den Systemaufruf tatsächlich durchzuführen?

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 seccompFilter 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 SIGSYSSignal 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.)

...

verwandte Informationen