Mir ist irgendwo nicht ganz klar wie man solche Fehler entdeckt. Sitzt da echt jemand da der den ganzen Quellcode (zumal es sich ja bei den meisten Projekten um nicht all zu wenig von diesem handelt) durchließt und so auf eventuelle Fehler stößt? Der Code ist ja höchstwahrscheinlich auch relativ komplett, über diverse Sachen würde man doch normalerweise einfach hinweglesen.
Zitat Brand Sprengler: "I exploit a bug that by looking at the source is unexploitable". Aufgrund der Tatsache dass der Fehler (der Compiler dereferenziert eine if-Abfrage) erst nach dem compilen vorhanden ist, wird er es tatsächlich via Trial&Error gefunden haben.
Von Aina fohn Fiehlen am So, 19. Juli 2009 um 20:32 #
Wie macht man das? Gibts dafür graphische Programme unter Linux? Die Konsolenprogramme sind sehr usability-fern. w32dasm läuft zwar in Wine, aber etwas Natives wäre schon coola.
Wieso sollten die "Konsolenprogramme" usability-fern sein? Es müsste afaik reichen wenn du den entsprechenden Teil mit einem großen Satz an Breakpoints compilierst und anschließend kompilierst (optimiert natürlich, weiß aber jetzt nicht wie man das mit GCC z.B. in einklang mit den Breakpoints bringt. Geht aber sicherlich, einfach mal die Doku durchlesen).
Wer sich mal so manche BlackHat/ Folien anschaut, dann sieht man, dass die Leute viele kleine minitools schreiben (oft in python/ruby), die bestimmte Muster in binär code suchen, die evt. exploitbar sind. Und das wird dann als Ausgangspunkt für weitere Analysen verwendet.
> Aus diesem Grund optimiert GCC die spätere Abfrage auch weg: Es nimmt an, dass diese Stelle im Code nicht erreicht werden kann, falls ein NULL-Zeiger vorliegt.
Ist ja auch völlig in Ordnung. Bei einem Zugriff auf einen NULL-Zeiger ist das Verhalten lt. C-Standard undefiniert. Also kann und darf der Compiler annehmen, dass eine nachträgliche Überprüfung unnötig ist, da das Programm angestürzt sein müsste - eigentlich. Ziemlich traurig, dass die Leute vom GCC jetzt auch noch Anfängerfehler bearbeiten müssen.
jedenfalls kann man jetzt mal die neue Option verwenden um zu gucken, welche Tests denn _NICHT_ mehr weg optimiert werden, und überall dort sind Bugs der gleichen Art. Und dazu muss ich nicht in den Quellcode gucken, das macht dann sogar der Compiler automagisch.
Von Michael Lehmeier am Mo, 20. Juli 2009 um 09:27 #
Mich würde auch mal interessieren, wie man eine Dereferenzierung eines Nullpointers als "erlaubt" ansehen kann. Ich meine, welchen gültigen Anwendungsfall gibt es denn? Wurde das irgendwo erklärt?
So wie es scheint, war es ein eindeutiger Fehler vom Programmierern, nicht GCC. Wenn ein Verhalten undefiniert ist, kann GCC dann machen was es will. Wenn der Fehler jetzt nicht aufgetreten wäre dann spätestens dann, wenn ein anderer Compiler verwendet worden wäre, der den undefinierten Fall dann anders interpretiert hätte. Wäre vielleicht sogar gut gewesen: Hätte es sofort einen Absturz gegeben.
Überheblich ist wohl noch untertrieben. In dem Quellcode des "super fun"-exploits verlinkt er unter anderem diverse Youtube-Videos, macht sich über Kernel-Entwickler lustig und zieht sogar Keyboard Cat mit rein
Von Andi Halbrecht am So, 19. Juli 2009 um 20:27 #
"Die überhebliche und großsprecherische Art [...]" Ist das nicht ein bisschen dreist, ihn auf diese Weise in ein schlechtes Licht rücken zu wollen? Ganz zu schweigen von den sozialen Auswirkungen, die das auf ihn haben könnte. Ich hätte jedenfalls ein Problem damit, über mich so etwas öffentlich lesen zu müssen und würde mich darüber prächtig ärgern. Es würde gar einer Schande gleichen, von Peinlichkeit und Scham übertroffen.
Gut, dass ich dieses Programm nicht nutze. Bei einem so inkompetenten Entwickler... Aber so sind wir Geeks nun mal. Sozial unterste Schublade, dafür technisch kaum zu übertreffen. Somit sollte man schon Verständnis zeigen können.
Wenn ich seine Frau wäre, würde ich mich langsam in Sicherheit bringen LOL
(Kenne ihn nicht, und verstehe auch die Hintergründe nicht, warum da so eine Haltung seiner Person den Linux-Entwicklern entgegen steht. Aber ich gehe davon aus, dass es einen Grund hat. Ich zitiere mal den Merowinger aus Matrix: Kausalität. Jede Wirkung hat seine Ursache.)
Ich bin froh, wenn Exploits entdeckt und gefixt werden!
Ich habe bei mir einen Vanilla-Kernel (2.6.30.1) im Einsatz und wollte den Exploit gerade testen, weil ich auch das "tun" Modul benutze (für vpnc). Bei mir kommt aber immer der Fehler: foo@localhost ~/Temp/cheddar_bay $ ./cheddar_bay.sh pulseaudio: Kein Prozess abgebrochen [+] Personality set to: PER_SVR4 Pulseaudio does not exist!
Der Exploit nutzt also PulseAudio, was ich natürlich nicht benutze. Ich finde, es ist einfach "Bullenschei*e", von einem Kernel-Exploit zu sprechen, wenn man dafür ein Programm nutzt, welches als root läuft.
Selinux braucht also nicht nur in mehr oder weniger regelmäßigen Abständen die begrenzten Nervenresourcen auf (Vista for Tux ), sondern scheint auch überflüssig/nutzlos zu sein? Ich hab's jedenfalls aus dem erstgenannten Grund schon längst abgeschaltet.
Der Code ist ja höchstwahrscheinlich auch relativ komplett, über diverse Sachen würde man doch normalerweise einfach hinweglesen.
Aufgrund der Tatsache dass der Fehler (der Compiler dereferenziert eine if-Abfrage) erst nach dem compilen vorhanden ist, wird er es tatsächlich via Trial&Error gefunden haben.
Es müsste afaik reichen wenn du den entsprechenden Teil mit einem großen Satz an Breakpoints compilierst und anschließend kompilierst (optimiert natürlich, weiß aber jetzt nicht wie man das mit GCC z.B. in einklang mit den Breakpoints bringt. Geht aber sicherlich, einfach mal die Doku durchlesen).
Gruß,
demon
Ist ja auch völlig in Ordnung. Bei einem Zugriff auf einen NULL-Zeiger ist das Verhalten lt. C-Standard undefiniert. Also kann und darf der Compiler annehmen, dass eine nachträgliche Überprüfung unnötig ist, da das Programm angestürzt sein müsste - eigentlich.
Ziemlich traurig, dass die Leute vom GCC jetzt auch noch Anfängerfehler bearbeiten müssen.
lg
Erik
Aber dafür muss man nicht irgendwelche sinnentleerten neuen Flags für den Compiler reinhacken.
Ach was solls, -Wall -Wextra machen ja schliesslich nur Anfänger...
Richtig. Bei -Wall reicht das völlig.
lg
Erik
jedenfalls kann man jetzt mal die neue Option verwenden um zu gucken, welche Tests denn _NICHT_ mehr weg optimiert werden, und überall dort sind Bugs der gleichen Art. Und dazu muss ich nicht in den Quellcode gucken, das macht dann sogar der Compiler automagisch.
Gruss,
Kay
Ich meine, welchen gültigen Anwendungsfall gibt es denn? Wurde das irgendwo erklärt?
So wie es scheint, war es ein eindeutiger Fehler vom Programmierern, nicht GCC. Wenn ein Verhalten undefiniert ist, kann GCC dann machen was es will. Wenn der Fehler jetzt nicht aufgetreten wäre dann spätestens dann, wenn ein anderer Compiler verwendet worden wäre, der den undefinierten Fall dann anders interpretiert hätte. Wäre vielleicht sogar gut gewesen: Hätte es sofort einen Absturz gegeben.
(Kenne ihn nicht, und verstehe auch die Hintergründe nicht, warum da so eine Haltung seiner Person den Linux-Entwicklern entgegen steht. Aber ich gehe davon aus, dass es einen Grund hat. Ich zitiere mal den Merowinger aus Matrix: Kausalität. Jede Wirkung hat seine Ursache.)
Ich bin froh, wenn Exploits entdeckt und gefixt werden!
canny75
Bei mir kommt aber immer der Fehler:
foo@localhost ~/Temp/cheddar_bay $ ./cheddar_bay.sh
pulseaudio: Kein Prozess abgebrochen
[+] Personality set to: PER_SVR4
Pulseaudio does not exist!
Der Exploit nutzt also PulseAudio, was ich natürlich nicht benutze. Ich finde, es ist einfach "Bullenschei*e", von einem Kernel-Exploit zu sprechen, wenn man dafür ein Programm nutzt, welches als root läuft.