Exploit für do_brk kernelbug?

[Dolly Buster]

Hallo,

ich suche einen ausführbaren Exploit für den do_brk() kernelbug. Alles, was ich bisher gefunden habe, ist das hier

http://securityfocus.com/archive/1/3461 ... 03-12-05/0

aber das funktioniert nicht bei mir ausserdem versteh ich das nicht (ich glaub mein nasm von woody mag das nicht)

Hat jemand etwas ferti8g kompiliertes, dass vorhandene Systeme tetet?

DANKE!

[Operations]

Hallo Dolly Buster,

... ich suche einen ausführbaren Exploit für den do_brk() kernelbug.

Die einfachere Variante wäre den Kernel 2.4.23 zu einzusetzen (auf Kernel 2.4.23 zu updaten) bzw. den gepatchten 2.4.18 aus den Security Updates, welcher schon den erforderlichen Patch enthält. Dann ist es auch nicht mehr notwendig das (fremde ) System darauf zutesten.


MFG

Operations

[spiffi]

Hm, hab den Exploit grad mal auf nem Woody durch den NASM gejagt. Assembliert einwandfrei.
Auf nem 2.4.23-xfs-grsec führt das Starten dieses Exploits jedoch zu nem segfault. Mit nem 2.4.22 hab ich's noch nicht ausprobiert, hab keine Lust meinen Router neu zu booten

[pdreker]

Auf nem 2.4.23-xfs-grsect das Starten dieses Exploits jedoch zu nem segfault.

Was für eine Überraschung, dass der Zugriff auf Kernelspeicher vom Userland aus unter GRSec zu einem SegFault führt...

Frei nach dem Motto: Wenn ich mit *meinem* Fahrzeug (Marke Leopard 2) gegen einen Baum zu fahren versuche kippt irgendwie immer der Baum um...

SCNR

Patrick

[Chimerer]

aber das funktioniert nicht bei mir ausserdem versteh ich das nicht (ich glaub mein nasm von woody mag das nicht)

http://securityfocus.com/archive/1/3462 ... 03-12-05/2

[spiffi]

Auf nem 2.4.23-xfs-grsect das Starten dieses Exploits jedoch zu nem segfault.

Was für eine Überraschung, dass der Zugriff auf Kernelspeicher vom Userland aus unter GRSec zu einem SegFault führt...

Nix für ungut Patrick, aber ich finde das schon verwunderlich, denn
a) hieß es das der 2.4.22 auch mit grsec exploitable sei, sprich der grsec-Patch nicht vor diesem Bug schützt.
b) wenn der grsec-Patch unerlaubte Zugriffe abfängt, dann wird das üblicherweise im syslog protokolliert. Das war hier nicht der Fall.

[pdreker]

Ja, habe ich mittlerweile auch herausgefunden, dass GRSec nicht vor dem Exploit schützt. Allerdings enthält GRSec ja auch PaX und evtl. stimmen da irgendwelche Parameter in dem Exploit nicht mehr, so dass er segfaulted. Immerhin ist das Assembler und man muss Dinge tun, die eigentlich nicht vorgesehen sind. Kann schonmal passieren, dass das nicht geht...

Die Ursache, das GRsec hier nicht greift, ist, dass man mit dem Exploit *direkten* Zugriff auf den Kernelspeicher bekommt. Man muss kein vorgegebenes Interface benutzen, wie z.B. /proc/kmem (Was von GRSec verhindert würde). Der Bug führt im Prinzip dazu, dass der Kernel denkt, dass der Kernelspeicher Teil des Prozesses ist, und damit werden *gar keine* Checks gemacht, bei denen das Problem auffallen könnte (Der Bug Fix implementiert übrigens genau diese Checks). Daher wird GRSec überhaupt nicht gefragt, und der Exploit funktioniert... PaX randomisiert ja einiges im Adressraum, so dass der Exploit schlicht nicht mehr trivial funktioniert, aber grundsätzlich sollte er (mit eine paar Modifiaktionen...) gehen. Da es aber keinen Bufferoverflow gibt, kann PaX die Ausführung auch nicht verhindern... Der SegFault ist wohl eher Zufall...

Patrick