m313 Security Blog

Todos conocemos el gran revuelo armado por el bug descubierto en el núcleo de Linux. Desde el punto de vista técnico este fallo ha sido muy grave porque permitía una escalada local de privilegios muy sencilla al estar disponible un exploit( en realidad varias versiones ) que aprovechaban dicha vulnerabilidad.
La historia es conocida, dejo varias referencias:

http://open-eslack.org/php/news.php?readmore=60
http://www.kriptopolis.org/bug-kernel-linux
http://barrapunto.com/article.pl?sid=08/02/11/106213

El bug fue noticiado en SecurityFocus el 8 de Febrero a las 12 horas.
En la pagina oficial del Kernel de Linux la nueva release con el bug corregido vió la luz el 10 de Febrero a las 16:47.
Hoy no voy a hablar de lo buena que ha sido la reacción de los desarrolladores ni nada de eso, solo quiero establecer una comparativa de respuesta por parte de las distintas distribuciones, centrandome en las más populares y haciendo un breve análisis por familias.

Los datos de disponibilidad del paquete oficial corregido son los siguientes:

Slackware 12: 11 Febrero a las 17:46.
Zenwalk 5: a fecha de edición de este artículo no he encontrado el advisory.
Vector Linux 5.8: a fecha de edición de este artículo no he encontrado el advisory.
Debian 3.1: 11 Febrero sin especificar hora.
Mandriva 2008: 12 Febrero sin especificar hora.
Gentoo: a fecha de edición de este artículo no he encontrado el advisory.
Ubuntu: 12 Febrero sin especificar hora.
Fedora 8: 11 Febrero a las 15:39.
OpenSuse 10.3: 12 Febrero a las 14:00.
Arch Linux : UPDATED: 10 de Febrero sin especificar hora.

No voy a poner grafiquitos ni nada de eso( soy partidario de la filosofía KISS ) pero si me gustaría comentar algunas ideas:

En primer lugar lo extraño que me parece que Gentoo a fecha de este artículo no haya siquiera publicado el aviso, creo que no he sabido encontrarlo o que debe de haber alguna razón para ello, omito por tanto comentarios sobre esta distribución que me merece un gran respeto, nos in antes decir lo grave que me parecería esta situación.
En segundo lugar destacar que la referencia en la resolución de estas vulnerabilidades han sido las distribuciones más usadas, UPDATED: Destacando a Arch Linux que gana a las demás por un dia de diferencia, Fedora a la cabeza, Slackware y Debian. ¿He dicho las más usadas? Sinceramente no creo que Slackware sea de las más usadas, pero ahi está, la segunda más rapida en contestar.
Esto me hace pensar en uno de esos mitos sobre slack, aquel de que los paquetes son obsoletos, que en Slackware se usa software anticuado y en general todas esas cosas que se dicen desde la ignorancia y que con el conocimiento en la mano caen por su propio peso.

Si separamos los datos por familias vemos que si de RPM’s se trata Fedora ha ganado la partida, una distribución muy sería con una empresa preocupada por la seguridad( y por las ventas ). Por detrás vemos la reacción de Mandriva y OpenSuse. No me sorprende que estas ultimas no estén a la cabeza.
En la familia de los paquetes DEB comprobamos de nuevo lo que algunos intuíamos desde hace tiempo: Debian no ha muerto. Puede que no esté Murdock a la cabeza y que Ubuntu les haya quitado publicidad y usuarios, pero los debianitas pueden enorgullecerse de que a nivel de seguridad la respuesta de su equipo de seguridad reafirma que su distro está más comprometida con la seguridad.
Entre los amantes de los TGZ’s es un dia de luces y sombras, si bien se confirma que Slackware marca la pauta en todos los aspectos y en seguridad también( no olvidemos, la tercera distribución en reaccionar de las analizadas ) se puede apreciar también que entre las distribuciones derivadas no tienen esa misma preocupación. Zenwalk y Vector Linux no han sacado parche a dia de hoy o yo no he sabido encontrarlo. No sé porque pero tampoco esto me sorprende.

Como conclusión pienso que si estás interesado en la seguridad( o la necesitas ) deberías utilizar en tus sistemas Linux más críticos las distribuciones padres.
Las distribuciones derivadas suelen tener muy buena pinta, tener una web muy chula, mucha propaganda y su uso te convierte muchas veces en muy way, pero a la hora de la verdad vemos nuevamente cuales son la referencia.

Compártelo

Hace unos dias Teotihuacan ponía un mensaje en los foros de Ubuntu, lo más destacable era esto:
“There is a file that contains all the installation logs :
/var/log/installer/cdebconf/questions.dat
In this file, there is all the questions asked to the user abd all the user’s answers.
So, near the end of the file, we can find the user created during the installation… and its password (not hidden).”

Teotihuacan no se daba cuenta de que la seguridad de Ubuntu había quedado hecha añicos, y es que en dicho fichero se almacenaba la contraseña del primer usuario en texto plano, es decir, del que por defecto tiene privilegios de root.
De la gestión del error no podemos decir más que fue expléndida, en Launchpad lo resolvieron con celeridad.

La curiosidad técnica es que este fallo de seguridad solo afectaba a la versión 5.10, quedaba libre la anterior 5.04 y la Dapper, de desarrollo.

Queda fuera de toda duda que no podemos pasar por alto este fallo solo porque Ubuntu sea un Linux de código abierto. El error de diseño es gravísimo, aunque también hay que destacar la eficiencia de su solución una vez descubierto.
Tenemos de nuevo la reflexión sobre si la seguridad es la oscuridad. Hace unos dias Symantec cambiaba su vara de medir en los errores en navegadores y aceptaba los errores en sí, admitidos por las compañías o sin admitir. Como resultado de dicha elección IE Explorer pasaba a ser el navegador menos seguro y Mozilla Firefox el más seguro.
¿Es conveniente que se conozcan los errores de un programa? Es evidente que en el OpenSource, al estar centrados en el producto interesa que se sepan para solucionarlos cuanto antes, en el software propietario interesa solucionarlos, pero no que se sepan para dar mejor imagen de la compañía. Como resultado es posible ( y sucede ) que las compañías trabajan en solucionar fallos que el usuario final ignora que existan.

Hay por tanto dos formas filosóficas de recibir el fallo de Ubuntu: En la primera nos quejaremos de la gravedad y les echaremos la culpa por incompetentes y diremos que software libre no equivale a seguridad, y en la segunda nos alegramos porque nuestro software tiene un error menos por descubrir ( nunca estaremos libres de errores ) y porque el desarrollo del mismo es transparente a los usuarios finales, o quizá una mezcla de ambas.

Compártelo