Grave problema descubierto en los kernels 2.4 y 2.6x

“El problema está en como Linux reacciona con operaciones no disponibles para algunos protocolos. sock-sendpage y otros no comprueban que no haya punteros a NULL antes de "de-referenciar" las operaciones en la estructura de operaciones. En vez de eso, el kernel confía en la correcta inicialización de esas estructuras de proto-ops con esbozos (como sock-no-sendpage) en vez de punteros a NULL”.

Aqui el patch para corregir el problema, y este es el site con mas informacion del mismo.

Este es el mensage original de las personas que encontraron el agujero:

Linux NULL pointer dereference due to incorrect proto_ops initializations (CVE-2009-2692)
EDIT: this has been featured on Slashdot, OSNews and TheRegister
EDIT: Here is RedHat's official mitigation recommendation

Tavis Ormandy and myself have recently found and investigated a Linux kernel vulnerability. It affects all 2.4 and 2.6 kernels since 2001 on all architectures. We believe this is the public vulnerability affecting the greatest number of kernel versions.

The issue lies in how Linux deals with unavailable operations for some protocols. sock_sendpage and others don't check for NULL pointers before dereferencing operations in the ops structure. Instead the kernel relies on correct initialization of those proto_ops structures with stubs (such as sock_no_sendpage) instead of NULL pointers.

At first sight, the code in af_ipx.c looks correct and seems to initialize .sendpage properly. However, due to a bug in the SOCKOPS_WRAP macro, sock_sendpage will not be initialized. This code is very fragile and there are many other protocols where proto_ops are not correctly initialized at all (vulnerable even without the bug in SOCKOPS_WRAP), see bluetooth for instance.

So it was decided that instead of patching all those protocols and continue to rely on this very fragile code, sock_sendpage would get patched to check against NULL. This was already the way sock_splice_read and others were handled.

Since it leads to the kernel executing code at NULL, the vulnerability is as trivial as it can get to exploit: an attacker can just put code in the first page that will get executed with kernel privileges. Our exploit took a few minutes to adapt from a previous one:

$ ./leeches
// ------------------------------------------------------
// sendpage linux local ring0
// ---------------- taviso@sdf.lonestar.org, julien@cr0.org
// leeches.c:Aug 11 2009
// GreetZ: LiquidK, lcamtuf, Spoonm, novocainated, asiraP, ScaryBeasts, spender, pipacs, stealth, jagger, redpig, Neel and all the other leeches we forgot to mention!
Enjoy some photography while at ring0 @ http://flickr.com/meder
For our webapp friends, here is an XSS executing at ring 0: javascript:alert(1);
shellcode now executing chmod("/bin/sh", 04755), welcome to ring0
Killed
$ sh
# id
uid=1000(julien) gid=1000(julien) euid=0(root)

On x86/x86_64, this issue could be mitigated by three things:
the recent mmap_min_addr feature. Note that this feature has known issues until at least 2.6.30.2. See also this LWN article.
on IA32 with PaX/GrSecurity, the KERNEXEC feature (x86 only)
not implementing affected protocols (a.k.a., reducing your attack surface by disabling what you don't need): PF_APPLETALK, PF_IPX, PF_IRDA, PF_X25, PF_AX25, PF_BLUETOOTH, PF_IUCV, IPPROTO_SCTP/PF_INET6, PF_PPPOX, PF_ISDN, but there may be more. (Update: See RedHat's mitigation)

From: Tavis Ormandy (tavisosdf.lonestar.org)