Login Barrapunto
Corregida vulnerabilidad en el núcleo Linux
lorenzohgh nos cuenta: «Hoy las listas de seguridad han recibido un nuevo aviso desde ISEC , esta vez Paul Starzetz y Wojciech Purczynski han descubierto una vulnerabilidad
grave en la llamada de sistema mremap relacionada con la gestión de memoria del kernel y una incorrecta comprobación de los límites de cada área de memoria.» En kernel.org ha aparecido inmediatamente el núcleo 2.4.24 que corrige este problema y muy poco más, con un changelog especialmente breve.
«Usando una llamada do_mremap() correctamente formada se puede crear un area de memoria virtual con una longitud de 0 bytes e inyectar código en formato hexadecimal o shellcode para ganar privilegios de uid0 ( root ) o ejecutar cualquier código bajo los privilegios del ring0 ( ejecución de nivel del kernel ).
Según Paul , la posibilidad de este compromiso se basa en que el comportamiento del kernel ante una situación de un area corrupta de 0bytes permite predecir el area de memoria que usará y por lo tanto usando cualquier instrucción que encuentre en ese bloque ( por un agujero de memoria en la VMA , memoria virtual ).
Más información:
- http://isec.pl/vulnerabilities04.html
- http://isec.pl/vulnerabilities/isec-0013-mremap.tx t
NOTA: Este fallo afecta desde las versiones 2.2.x a las 2.6.x ( 2.4.z incluidas )»
Según Paul , la posibilidad de este compromiso se basa en que el comportamiento del kernel ante una situación de un area corrupta de 0bytes permite predecir el area de memoria que usará y por lo tanto usando cualquier instrucción que encuentre en ese bloque ( por un agujero de memoria en la VMA , memoria virtual ).
Más información:
- http://isec.pl/vulnerabilities04.html
- http://isec.pl/vulnerabilities/isec-0013-mremap.tx t
NOTA: Este fallo afecta desde las versiones 2.2.x a las 2.6.x ( 2.4.z incluidas )»
Este hilo ha sido archivado.
No pueden publicarse nuevos comentarios.
Corregida vulnerabilidad en el núcleo Linux
|
Log in/Crear cuenta
| Top
| 61 comentarios
| Buscar hilo
Y recuerda: Los comentarios que siguen pertenecen a las personas que los han enviado. No somos responsables de los mismos.

De Tiempo y tocinos
(Puntos:2, Interesante)[Full-Disclosure] Linux kernel mremap vulnerability
Paul Starzetz security@isec.pl
Mon, 5 Jan 2004 13:30:32 +0100 (CET)
The latest 2.4 version of the Linux kernel is: 2.4.24 2004-01-05 13:55 UTC
despues de realizar la conversion a UTC tenemos que la publicacion en la Full-Disclosure fue a las 11:30:32 UTC y el Kernel 2.4.24 a las 13:55.
Re:De Tiempo y tocinos
(Puntos:4, Inspirado)Lo siento, pero te equivocas en el razonamiento.
Hay fallos que existen desde siempre, en Linux, Windows y en cualquier software.
Otro tema es que cuando se conocen se solvente rápido o no.
Este comentario se refiere al tiempo en que se descubre y se solventa.
El tema del RPC que explotaba Blaster existe desde la primera versión de Windows NT 4.0 (año 96), pero no descubrió hasta hace pocos meses. Y esto no quiere decir que Microsoft sea lenta, sino que no se descubrió y, por lo tanto, como si no existiera.
Repito, todo software tiene problemas, unos se conocen y otros no. No puedes arreglar algo que no sabes que existe.
Saludos.
Pregunta
(Puntos:2, Inspirado)¿Cómo c*ñ* descubre alguien este tipo de errores? ¿Se topan con ellos por casualidad o les sobreviene una inspiración divina?
Hace falta tener una cuenta local.
(Puntos:1)( http://quae.net/ )
el fallo se detectó hace por lo menos TRES semanas
(Puntos:1)--------------------------------------------------
* Wed Dec 17 13:00:00 2003 - mantel@suse.de
- add missing check in mremap
vaya mesecitos
(Puntos:2, Inspirado)( http://barrapunto.com/ )
Lo que no hay que hacer es criticar a Linux por sus errores o aprovechar para criticar a Microsoft tambien de paso. El software tiene errores y siempre los tendra. Si alguien hace un programa y considera que no puede tener ningun error, casi seguro que se equivoca. Todos los programas tienen errores, que pueden aparecer muy frecuentemente o en casos extremos. Estos ultimos son los mas complejos de detectar, porque o se detectan en correctas baterias de test, o es improbable detectarlos en funcionamiento. Este error es uno de estos.
El gran problema que tiene Linux frente a Microsoft es que, aunque el kernel haya sido actualizado, no se puede asegurar que todas las distribuciones hayan parcheado inmediatamente su distribucion de manera que mañana todos los administradores puedan descargar un nuevo kernel parcheado. Deberia ser obligatorio que todas las compañias que ofrecen soporte pagado lo tuvieran, porque viven de eso, del soporte, mientras que es mas tolerable que distribuciones que no cobran, como gentoo o debian, tarden algo mas en actualizar. Supongo que gentoo hara la actualizacion casi inmediatamente, pero bueno, seria tolerable que tardaran mas.
De los que se compilan el kernel no digo nada, porque se lo que nos gusta hacer el make del kernel y ver lo bonito que queda.
Lo que es la MANIPULACION informativa.
(Puntos:3, Interesante)
Pero es que sois iguales. Se desubre una muy grave vulnerabilidad del kernel, que afecta a la practica totalidad de las instalaciones linux... y la noticia se reduce a un "Corregida vulnerabilidad en el nucleo de Linux" (redundante por cierto, porque Linux es solo un kernel).
Solo se ha hecho la correcion para la serie 2.4, las otras dos 2.6 y 2.2 todavia la padecen, luego el titular de la noticia es todo un alarde de desinformacion. Ademas, el que cualquier usuario de cualquier sistema linux pueda ganar privilegios de root, no me parece "grave". Personalmente el sentido comun me dice que como poco es "muy grave".Re:A ver cuanto tardan...
(Puntos:1, Interesante)Me parece realmente acojonante que ahora os "quejeis" (o te quejes) de los trolls de microsoft,cuando un altisimo porcentaje de vosotros mete cizaña contra m$ por el mero echo de meterla,por ir de way,etc
Y en este caso concreto de meter cizaña sobre los bugs ajenos ( si fuese un bug de m$ ya me imagino como estaria el percal ) ,pues quizas no haya mas "trolls microsoft" por aqui porque ,al menos en mi caso,no me dedico a "vivir" de los errores de los demas,ni a estar mirando constantemente lo que hace para decir "otro fallo de kernel de linus,juajuajua son la oxtia estos linuserox XDDDDD" . ale
Re:A ver cuanto tardan...
(Puntos:1)Re:esfuerzos disgregados, falta de estandares...
(Puntos:3, Interesante)( http://www.halftimerockband.net/ )
¡Ah! Y en cuanto a lo de "disgregar esfuerzos", yo prefiero llamarlo "libertad de elección". Me gusta poder elegir entre Gnome o KDE, me gusta poder elegir entre Mplayer o Xine, me gusta poder elegir entre OpenOffice y KOffice, me gusta poder elegir entre... en fin, que me gusta. Y gracias a la GPL no se duplican tantos esfuerzos, porque una buena idea implementada en un programa se puede pasar al de la "competencia" sin mucho esfuerzo.
-
La belleza está en el interior (Jack el Destripador)
Re:esfuerzos disgregados, falta de estandares...
(Puntos:1)( http://blackspiral.org/ | Última bitácora: Miércoles, 03 Diciembre de 2003, 19:23h )
¿Te refieres a algo similar a POSIX [pasc.org]?
De todas formas yo tampoco entiendo muy bien qué tiene que ver la estandarización de las distribuciones con la seguridad del kernel. No nos olvidemos que el fallo afecta directamente al núcleo, no a alguna aplicación aparte. Y en el núcleo, pese a haber forks y pese a que algunas distros lo parcheen al gusto, la base es la misma sobre la que está trabajando todo cristo.
Y desde luego, yo no cambio la libertad de elección que tengo ahora con los distintos sabores de linux y esas pequeñas diferencias entre distribuciones que se ajustan en cada momento a tus necesidades por nada del mundo. ¿No está precisamente ahí la gracia?. Para usar todos lo mismo, pues usemos microsoft. Bueno, en este caso, la alternativa libre, debian según tengo entendido, ¿no? ;).
Un saludo--
Icarus
"It's not a bug, it's a feature!"