Barrapunto

miusuario@MiHost:~$ uname -a
Linux MiHost 2.4.18 #1 jue mar 13 17:00:32 CET 2003 i686 unknown unknown GNU/Linux

miusuario@MiHost:~$ ./isec-ptrace-kmod-exploit
[-] Unable to attach: Operation not permitted
Killed

Y no he aplicado ningun parche....
¿No eran vulnerables todos los 2.4? ¿ese exploit no sirve para mi kernel?

Saludos.

Sacado de Slashdot:
echo "/fichero/que/no/existe" > /proc/sys/kernel/modprobe

Aconsejado meterlo en algun script de arranque. A primera vista parece que me ha funcionado.

Tronco, leete los enlaces de la noticia:

http://www.spinics.net/lists/kernel/msg162986.html

Con un 2.2.20 de kernel.org, creo que limpio sin ningún parche, no funciona el exploit.

$ ./a.out
[-] Unable to attach: Operation not permitted
Killed

En mi debian tb cuela...

Veo, padre, hijos, sockets...alguien que se curre una explicacion precisa de lo que hace?

Y si no hay soporte para módulos tampoco funciona, por lo que parece (suerte que mi máquina la tengo con el soporte de módulos desactivados)

de todas formas, pronto a cambiar el kernel :-)

Hago root igual (Mandrake 9.0, kernel 2.4.19-16mdk) :P No parece que sirva con mi kernel.

Esa máquina no tiene soporte para módulos y si el error está en kmod es normal que no funcione el exploit

A mi no me fuciona eso: manje@bf:~/tmp$ su Password: bf:/home/manje/tmp# echo "/fichero/que/no/existe" > /proc/sys/kernel/modprobe bf:/home/manje/tmp# exit manje@bf:~/tmp$ ./a.out sh-2.05a#

Pues teneis razón. A mi me ha funcionado un par de intentos, se quedaba parado en el [+] Attached to ..., pero ahora sí que vuelvo a conseguir root.

Segun veo en el codigo creo que es solo para arquitecturas basadas en 386, no ?

El parche de Alan es para el 2.4.20 y yo tengo el kernel off-the-box de MDK (2.4.19-16mdk) que supongo llevará parches exóticos por un tubo.

El parche es para el 2.4.20 y yo tengo las fuentes del 2.4.19-24mdk (corriendo el 2.4.19-16mdk).

[root@localhost linux-2.4.19-24mdk]# patch -p1 alan_ptread_patch
patching file arch/i386/kernel/process.c
Hunk #1 succeeded at 496 (offset 1 line).
Hunk #2 FAILED at 519.
1 out of 2 hunks FAILED -- saving rejects to file arch/i386/kernel/process.c.rej

En el parche he quitado todo lo correspondiente al resto de las arch y he dejado sólo la parte para i386...

Bueno, vienen los parches grsecurity, que me da bastante grimilla poner porque siempre joden algo (no, si para un servidor en producción estarán muy bien, pero la mía es una máquina de desarrollo con muuchas cosas experimentales y 'raritas'...

Va, habrá que hacerse con un vanilla, qué remedio.

¡¡¡ Me Cago en Tos Sus Muelas !!!

Pues parece que no, el parache cambia de nombre a la funcion kernel_thread a arch_kernel_thread , en todas las arquitecturas. Y crea de nuevo la funcion kernel_thread que no es mas que un wrapper a arch_kernel_thread evitando el bug.

Bueno eso es lo que yo he entendido, puedo estar equivocado.

merlin:~$ ./malomalo
[-] Unable to attach: Operation not permitted
Terminado (killed)
merlin:~$

Parece que con el kernel de SuSE 8 (sin compilar ni nada) tampoco va (fiuuuu). :)

Creo que si es el kernel que te instala alguna distribución (y no uno que tú te hayas compilado) puede ocurrir que no sea vulnerable. Al menos el mío no lo es, y no es monolítico.

Linux yo 2.4.18-4GB #1 Wed Mar 27 13:57:05 UTC 2002 i686 unknown

Buff, el de Mandrake 9.0 trae ese parche, pero no viene activado por defecto. Hay que recompilar (en la 9.0 download por lo menos) y no he encontrado versión 'secure' de este kernel. De todas formas es un alivio, pue no he enocntrado el parche y bajarme un vanilla ahora como que me da un poco de grimilla.

Eso me temo, juas.

De todas formas, un apunte:

En este caso en particular, hacer mención de la distribución de cada uno es algo bastante importante.

hay que tener en cuanta que ahora no estamos intercambiando opiniones a ver quién es más 'Güay'; estamos tratando un problema de seguridad y dando claves para solucionarlo de la forma en la que la comunidad de Soft Libre sabe trabajar.

Ante un problema de estas carácterísticas puede ser vital para un sysadmin que esté al cargo de una red Linux heterogénea saber si una distro en particular no está afectada, si su kernel "off-the-box" es vulnerable o no (Mandrake trae el grsecurity, Red Hat no, DEbian lo ignoro, SuSE sí...).

Vamos que en este caso en particular creo que sería casi obligatorio especificar la distro de cada uno.

Así que me gustaría pedir por favor que por lo menos en este caso se abstuviera la gente de hacer los estúpidos comentarios sobre Debian o Dejabandedeber y al hilo del que 'trollificó' el primero: Sí la noticia está en portada y es por supuesto donde tenía que estar un aviso de seguridad.

¿O es que los usuarios de Debian ahora tampoco van a poder intercambiar información sobre fallos en el kernel?

EMHO se está pasando de una situación de queja por quizá exeso de distro-centrismo a una verdadera caza de brujas en la que con sólo mencionar apt ya te flamean (y eso cuando lo usaba con la Red Hat).

Siguiendo así todo el valor de ser comunidad,m que se demuestra en casos como este, se irá a tomar por el puto culo para alegría del tío Haselfroch.

Hostias, tienes razón, que metedura de gamba.
Pido disculpas.

Yo en mi infinita estupidez e ignorancia estaba convencido de que *antes* de que se publicar el fallo el sysadmin no sabía que es fallo existía (claro, los que nos hemos enterado por aquí somos unos simios inhumanos, mañana mismo me suicido, lo juro).

Tambíen pensaba que las distros estaban ya instaladas y que los desarrolladores de las distros cuando las sacaron meses o semanas atrás no sabían que en el futuro se iba a encontrar este bug en particular.

Claro, en mi, repito, infinita estupidez no había podido saber que los sysadmins y los desarrolladores de las distros poseen *Superpoderes Cuánticos*, unos para saber que iba a aparecer este bug (no lo he encontrado en Securityfocus ni en la lista, no he mirado hoy por casualidad buqtraq, soy estúuuuuuuupido) y las distros para sacar versiones parcheadas meses o semanas ántes de que apareciera el bug.

Y claro, si tengo una red con digamos veinte PC's algunos sin acceso directo (WLAN por ejemplo) es muy fácil ir compilando el exploit en cada una a ver si funciona. Es fácil, claro, lo que pasa es que algunos somos unos estúpidos, estúpidos subnormales, premios nobel de la subnormalidad y carecemos de esos *Superpoderes Cúanticos*

Me has convencido, no se hable más, voy a liberar a la humanidad de una carga que no se merce soportar suicidándome a lo bonzo.

(A Propos, ¿SE pueden aprender los *Superpoderes Cuánticos*)

Lo dudo. Si el error está en el kernel muy probablemente afecte a TODAS las arquitecturas. Aunque el procesador sea distinto, la lógica del software no lo es, y no es un error hard.... Saludos

Amos a ver..... Es un error del Kernel.... NO IMPORTA LA DISTRO... Eso si, cada distro sacará los parches que estime oportunos, pero si actualizaste el kernel por tu cuenta... a parchear por tu cuenta. QUE ES EL MISMO SO. LO DE LAS DISTROS ES secundariooooo...

Hombre, no se.....

pero por lo menos actualizar el kernel o parchearlo.... (redhat por lo menos, tiene un rpm con kernel inmune a este problema...). ¿compilando el exploit en cada una...? ¿de qué estás hablando? ¿cada equipo tiene un kernel distinto?... pos bueno....

Si que lo tengo amigo :-)
Por ejemplo...

MiHost:/home/miusuario# lsmod
Module Size Used by Tainted: P
NVdriver 1064800 10
lp 6112 0

Tampoco es el kernel precompilado de ninguna distri, es un 2.4.18 de kernel.org compilado por mi mismo...

Mas ideas?

cada distribución suele llevar núcleos parcheados, muy pocas llevan vanilla, por lo tanto si depende de la ditribución, por poner un ejemplo me sorprendio gratamente ver que el kernel 2.4.20 de gentoo lleva incluido el parche del planificador O(1) que se esta preparando para el 2.6

Tienes soporte para "Kernel module loader support"? Ahí es donde está realmente el fallo.

Para que el exploit funcione hace falta un kernel con módulos (CONFIG_MODULES) y con el kernel module loader (CONFIG_KMOD), y con un ejecutable en el /proc/sys/kernel/modprobe. Además, el directorio en el que ejecutes el exploit tiene que estar en una partición en la que funcionen los set-uid.

> Segun veo en el codigo creo que es solo para arquitecturas basadas en 386, no ?

El fallo existe en todas las arquitecturas por igual.

El exploit en concreto que está por ahí utiliza código en ensamblador que evidentemente solo funciona en una arquitectura.

El programilla es cortito y sencillo, pero visto que al menos una persona ha pedido una explicación, pues bueno, allá va...

Lo primero que hace el programa es comprobar si ya somos root; en ese caso, simeplemente ejecuta una shell y sacabó.

Se generan dos procesos, de los cuales uno provoca que el kernel intene cargar un módulo llamando a "modprobe" y el otro espera a que ese modprobe se lance para hacer un ptrace() contra él y tomar el control.

Una vez que tiene el control de ptrace(), le injerta un pedacito de código en ensamblador que hace, básicamente:
chown(path_del_exploit, 0, 0);
chmod(path_del_exploit, 06755);
exit(0);

El programa principal se ha quedado todo el tiempo esperando a que el propio fichero del exploit cambie de modos y pase a ser un setuid; cuando esto sucede, se vuelve a ejecutar a si mismo, y al ser esta vez root el que está ejecutándolo, nos da una shell.

Tu verás como miras: