elhacker.net cabecera Bienvenido(a), Visitante. Por favor Ingresar o Registrarse
¿Perdiste tu email de activación?.
 
Inicio Ayuda Buscar Ingresar Registrarse
25 Mayo 2012, 09:27  


Tema destacado: ¿Eres nuevo? ¿Tienes dudas acerca del funcionamiento de la comunidad? Lee las Reglas Generales

+  Foro de elhacker.net
|-+  Seguridad Informática
| |-+  Bugs y Exploits (Moderador: berz3k)
| | |-+  CVE-2009-4005 - Linux Kernel 'hfc_usb.c'
0 Usuarios y 2 Visitantes están viendo este tema.
Páginas: 1 [2] Ir Abajo Respuesta Imprimir
Autor Tema: CVE-2009-4005 - Linux Kernel 'hfc_usb.c'  (Leído 3,447 veces)
sirdarckcat
Troll Buena Onda y
CoAdmin
***
Desconectado Desconectado

Mensajes: 6.947


Lavando Platos


Ver Perfil WWW
Re: CVE-2009-4005 - Linux Kernel 'hfc_usb.c'
« Respuesta #15 en: 20 Febrero 2010, 20:04 »

ese ultimo mensaje significa que x[-1] es lo mismo que *(x-1) que significa que no pasa nada si len es 0..


lo que me queda de posibilidad es:




Citar
no seria posible tambien pasar como len cualquier valor arbitrario? y hacer que el sistema trate de leer la memoria en 0x000000 o algo asi?

En línea

Ivanchuk


Desconectado Desconectado

Mensajes: 466


LLVM


Ver Perfil WWW
Re: CVE-2009-4005 - Linux Kernel 'hfc_usb.c'
« Respuesta #16 en: 20 Febrero 2010, 20:50 »

ese ultimo mensaje significa que x[-1] es lo mismo que *(x-1) que significa que no pasa nada si len es 0..


lo que me queda de posibilidad es:




Citar
no seria posible tambien pasar como len cualquier valor arbitrario? y hacer que el sistema trate de leer la memoria en 0x000000 o algo asi?



Yo creeria que no, porq el tamano maximo esta determinado de entrada en la inicializacion del driver por wMaxPacketSize.
Código:
/* set USB_SIZE to match wMaxPacketSize for INT or BULK transfers */
write_usb(hfc, HFCUSB_USB_SIZE,
  (hfc->packet_size / 8) | ((hfc->packet_size / 8) << 4));

/* set USB_SIZE_I to match wMaxPacketSize for ISO transfers */
write_usb(hfc, HFCUSB_USB_SIZE_I, hfc->iso_packet_size);

Si te fijas en la doc del chip la config del paquete usb esta codificada en 4bits como submultiplos de 8 para las transfers INT y BULK sobre una palabra de 8 bits, por eso divide por 8. Y en las transferencias isochronous por 7bits pero sin codificar en este caso. O sea que el valor maximo es de 128 para todas las transferencias.

Saludos.
« Última modificación: 20 Febrero 2010, 20:55 por Ivanchuk » En línea

Sólo quien practica lo absurdo puede lograr lo imposible.

Join us @ http://foro.h-sec.org
nitr0us

Desconectado Desconectado

Mensajes: 204


#rm -fr /


Ver Perfil WWW
Re: CVE-2009-4005 - Linux Kernel 'hfc_usb.c'
« Respuesta #17 en: 20 Febrero 2010, 22:52 »

Bueno, hay que aclarar que inicié el el análisis con enfoque Bottom-up a 1 nivel nada más, es decir, que solamente salí de la función vulnerable y no seguí subiendo niveles (funciones) para ver si los parámetros podían ser controlados por el usuario.

Citar
Esto no es del todo cierto, ya que el orden en el que se almacenan los bits dependerá de la arquitectura del procesador (Big Endian o Little Endian), así que sería más correcto decir que el bit de mayor peso (independientemente de donde se almacene) es el que se reserva para definir el signo en caso de interpretar el entero como SIGNED
Claro, supongo que la mayoría que siguió este post tenía en consideración el endianess de las arquitecturas.

Ivanchuck:
Citar
Me parece que un kernel panic en user-land no creo que se pueda provocar.
El código que puse del ELFcrash por ahí puse que era un ejemplo pero en user-land, un crash de un programa cuando intenta acceder a una dir. de memoria inválida, tal cual podría ser el caso en este bug de kernel. Y desde user-land como tal, tengo entendido que no puedes kernel panics, PERO !, si puedes pasarle parámetros al kernel desde user-land, este los malinterpreta y muere con un bonito panic.
Ejemplos? Slide #35 http://www.brainoverflow.org/presentations/ELF%20EN%20LA%20MIRA%20-%20HACKING%20Y%20DEFENSA%20-%20ENLI%2008.pdf

Screenshot??
http://www.brainoverflow.org/misc/nitr0us%20kernel%20panic.bmp


Saludos.
En línea

Ivanchuk


Desconectado Desconectado

Mensajes: 466


LLVM


Ver Perfil WWW
Re: CVE-2009-4005 - Linux Kernel 'hfc_usb.c'
« Respuesta #18 en: 21 Febrero 2010, 23:59 »

Bueno, hay que aclarar que inicié el el análisis con enfoque Bottom-up a 1 nivel nada más, es decir, que solamente salí de la función vulnerable y no seguí subiendo niveles (funciones) para ver si los parámetros podían ser controlados por el usuario.

Citar
Esto no es del todo cierto, ya que el orden en el que se almacenan los bits dependerá de la arquitectura del procesador (Big Endian o Little Endian), así que sería más correcto decir que el bit de mayor peso (independientemente de donde se almacene) es el que se reserva para definir el signo en caso de interpretar el entero como SIGNED
Claro, supongo que la mayoría que siguió este post tenía en consideración el endianess de las arquitecturas.

Ivanchuck:
Citar
Me parece que un kernel panic en user-land no creo que se pueda provocar.
El código que puse del ELFcrash por ahí puse que era un ejemplo pero en user-land, un crash de un programa cuando intenta acceder a una dir. de memoria inválida, tal cual podría ser el caso en este bug de kernel. Y desde user-land como tal, tengo entendido que no puedes kernel panics, PERO !, si puedes pasarle parámetros al kernel desde user-land, este los malinterpreta y muere con un bonito panic.
Ejemplos? Slide #35 http://www.brainoverflow.org/presentations/ELF%20EN%20LA%20MIRA%20-%20HACKING%20Y%20DEFENSA%20-%20ENLI%2008.pdf

Screenshot??
http://www.brainoverflow.org/misc/nitr0us%20kernel%20panic.bmp


Saludos.

Ah esta bien, como bug del kernel decis. Por cierto, es muy buena esa vulnerabilidad del fs que descubristes ;)
En línea

Sólo quien practica lo absurdo puede lograr lo imposible.

Join us @ http://foro.h-sec.org
Páginas: 1 [2] Ir Arriba Respuesta Imprimir 

Ir a:  
Powered by SMF 1.1.16 | SMF © 2006-2008, Simple Machines