Fragen? Antworten! Siehe auch: Alternativlos
pkexec ist ja nur die Quelle der Rechte, aber nicht der Root Cause des Exploits. Wie in https://seclists.org/oss-sec/2022/q1/80 geschildert, ist es ja glibc, genauer iconv, die da sinn- und sorglos .so-Files nachladen und ausführen.Fun fact: Von diesem fopen-css-Ding wusste ich auch noch nichts. Aber ich wusste, dass iconv in der glibc Code nachlädt und daher gefährlich ist, und dass die da von Hand irgendwelche Environment-Variablen filtern, wenn sie glauben, dass sie setuid laufen, und dabei auch schonmal was vergessen haben, und ich wusste, dass glib das alles implizit reinzieht. Ich fand glib auch aus anderen Gründen nie vertrauenswürdig und habe das daher nie in irgeneines meiner Projekte reingezogen. Manchmal ist es eine gute Idee, auf sein Bauchgefühl zu hören.Das ist auch keine neue Beobachtung, in 2014 hat Tavis bereits https://www.openwall.com/lists/oss-security/2014/07/14/1 darauf hingewiesen. Maybe someone can figure out how to turn this into something scary.
Und in 2017 ist der defekte Code in glibc bereits gefixt worden, aber ... in einer anderen Kopie des Codes, https://www.openwall.com/lists/oss-security/2017/06/23/8, in einem vollkommenen Versagen von Code-Handling und Versioning seitens der GNU Leute (also ist niemand überrascht).
Und 2019 hat jemand in https://hugeh0ge.github.io/2019/11/04/Getting-Arbitrary-Code-Execution-from-fopen-s-2nd-Argument/ gezeigt, wie man diesen Code über das 2. Argument von fopen(3) (ja, das "r"-Flag) triggert, also Code Execution von einem fopen("blafasel.txt", "r") bekommt. Okay, es ist ein fopen("blafasel.txt", "r,css=keks"), aber bitte. Das ist alles ganz wunderbar.
Ich programmiere seit 1983, mache C seit 1986 und lernte gestern vom ccs= Flag von fopen(3) in glibc. Ein weiteres Stück Bibliothek, das irgendwo im Dateisystem gefundene .so-Dateien reinlädt und anleckt, um zu sehen, ob man sie ausführen kann.
Ich bin mir sicher, das ist nicht das letzte Mal, daß wir von iconv im Kontext Exploits hören werden.