lcfr-eth/cve-2024-14027_slopExploits für CVE-2024-14027, erstellt mit AI/Claude als Test.
Die Exploits wurden auf 6.6.51 mit einer Qemu-Debian-Installation getestet.
exploit.c - wird die Shadow-Datei leaken.
exploit_dc.c - demonstriert die Double-Close-Methode, um eine Root-Shell zu erhalten.
WRITEUP.md - LLM-generierte Beschreibung.
Dies war ein Experiment unter Verwendung von LLM (Opus 4.6), um eine einzigartige Art von Kernel-Sicherheitslücke auszunutzen, die daher rührt, dass man ein Objekt desselben Typs, das freigegeben wurde, neu belegen/wiederverwenden kann, wie von grsecurity beschrieben.
Die Ergebnisse sind überraschend, wenn man bedenkt, dass der Fehler ohne LLM recht einfach auszunutzen ist. Die Ausnutzung ist unkompliziert und nahezu identisch mit den Referenz-Exploits von Mathias Krause (@_minipli).
Claude Code Opus 4.6 + gdb-mcp
Initialer Prompt:
there is a kernel vulnerability at this link that is used in a ctf, your name is bradley spengler the grsecurity kernel expert who knows how to
exploit kernels. it should work on 32bit only and 6.6LTS kernel .. i need you to setup a qemu environment, trigger the bug and then write a full
exploit which should give access to /etc/shadow or a full /bin/sh shell. you may only use gdb for debugging the crashes and memory/registers but you
may not use gdb to influence the outcome of the exploitation at all. in the end i want a qemu i can login to and test the exploit. here is the link
to the vulnerable code https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a71874379ec8c6e788a61d71b3ad014a8d9a5c08
Ich habe keine Ahnung, ob es etwas bringt, diese Dinge mit einer Identitätskrise aufzuputschen – es schien nichts Positives zur Lösung des Problems beizutragen. :>
Zu Beginn schien Claude nicht viel über diese Art von Sicherheitslücken der Wiederverwendung desselben Typs zu wissen und begann damit, nach Standardmethoden zu suchen, einen Slab zu korrumpieren -> ROP -> Shell. Ich habe es angestupst, indem ich dieses Repo heruntergeladen und es gebeten habe, die Exploits als Referenz zu überprüfen.
Ich dachte, es könnte daraus schließen und debuggen, um mit diesen Dateien allein einen Exploit-Plan zu erstellen, aber es drehte sich etwa 8 Stunden lang im Kreis (während ich schlief), bevor ich eingriff.
Am nächsten Tag, als ich eingriff und seinen Exploit überprüfte, machte es selbst mit den Referenz-Exploits nur halbe Sachen. Selbst mit dem Referenzcode führte sein eigenes check_fd eine einfachere Schleife aus, die nur mit fcntl(F_GETFL) auf O_RDONLY prüfte, ohne die fstat dev/ino-Prüfung, um /etc/shadow zu identifizieren. Es konnte die Shadow-Datei im Leak nicht zuverlässig finden und matchte allerlei Unsinn.
Das Polling auf den veralteten fd fand direkt im Elternprozess statt, anstatt in einem Fork, was den gesamten Exploit abtöten würde, wo er hätte fortgesetzt werden können..
Ich musste ihm mitteilen, dass seine Implementierungen falsch waren und es die genauen Implementierungen aus den Referenzen verwenden solle. Danach funktionierte der Exploit fast sofort.
Automatische Einrichtung einer Zielumgebung! Das war schön, weil ich faul bin :)
Es hat herausgefunden, wie man die 20-minütige Wartezeit verkürzen kann, indem man f_count=1 findet und setzt, um das Debuggen zu beschleunigen. Das scheint das zu sein, was jeder vernünftige Exploit-Entwickler ohnehin getan hätte.
Es hat schließlich die Exploits mit minimalem „Aufwand“ für mich in Bezug auf manuelles Debugging generiert. Mit etwas erforderlicher Aufsicht.
Insgesamt hat es jedoch den Anschein, als ob die Ausnutzung dieses Bugs viel länger gedauert hat, als nötig gewesen wäre, und manuell in deutlich kürzerer Zeit hätte erledigt werden können.
Man muss immer noch in der Lage sein, Code zu lesen, und ein gewisses Verständnis von xdev haben, um selbstständig zu denken und es in die richtige Richtung zu lenken.
Wird es besser werden? Natürlich..