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

En el marco del proyecto Embajadores Slackware he elaborado una pequeña presentación.
En ella se realiza un repaso sobre Slackware, funcionalidades, características, comunidad hispana, recursos y mitos que rodean a esta distribución. Esta presentación está pensada para ser usada en charlas y conferencias destinadas a un publico no slacker que pretenda acercarse a esta distribución.

Podéis descargarlas en el siguiente enlace.

Compártelo

Ultimamente estoy haciendo una presentación para el proyecto Embajadores Slackware que consiste en presentar slack para no iniciados, con sus beneficios, la comunidad hispana y un repaso por los mitos que rodean a la distribución activa más veterana de Linux.

Uno de esos mitos es la no resolución de dependencias en la paquetería tgz. Explicar que esto es debido a filosofía es un argumento muy pobre si tenemos en cuenta que esa presentación está pensada para ser utilizada en charlas a newbies.
Es por eso que incido sobre la posibilidad de resolución de dependencias que SI existe en Slackware Linux. Hablamos en este punto de los diversos programas existentes para ello. Haciendo un breve repaso de alguno de los más conocidos nos encontramos con 3 opciones:

- Swaret: es el que actualmente utilizo, tiene multitud de opciones y aunque la opción upgrade consume muchos recursos me parece el más completo, si bien es un programa un poco dejado de la mano de Dios si tenemos en cuenta la falta de actualización de la aplicación.

- Slapt-get: es un programa muy utilizado por los slackers debido a la simplicidad del mismo, es eficiente y dispone de una aplicación GTK para poder utilizarla muy comodamente en modo gráfico. Personalmente la he utilizado mucho, es un programa muy actualizado( quizás demasiado ) y toda una referencia.

- Slackpkg: es una utilidad pseudooficial( está incluida en la sección extras de slackware oficial ) y es la que menos he utilizado de las tres. En principio es la que mejor se adapta a la filosofía de Slackware ya que solo admite repositorios oficiales, es decir, nada de repositorios tipo linuxpackages.

Hasta aqui solo trato de explicar como es falso o semifalso aquello de que no hay resolución de dependencias en la paquetería tgz.
A partir de entonces paso a hablar de lo que yo denomino “minipaquetes” y de como en Slackware apenas se dan, lo que facilita a mi modo de ver enormemente la gestión de los paquetes.
Un minipaquete es aquel paquete que tiene un contenido mínimo y que podría estar englobado en uno más grande. La problemática de estos paquetes se da en sistemas con resolución de dependencias muy fuerte( ej: Ubuntu ) cuando al instalar un programa instalamos 20 paquetes deb y muchos de ellos no pasan de 50 KB. Esto en principio no es un problema ya que la fuerte resolución de dependencias nos deja un sistema estable, si bien es verdad que cuando listamos los paquetes instalados vemos un gran número de paquetes, de los cuales la mayor parte no sabemos ni qué son ni para qué sirven y eso sí es un problema tanto desde el punto de vista del administrador como desde el punto de vista de la seguridad.

El caso es que mientras preparaba este tema he descubierto un programa para Slack que analiza un sistema y contruye la relación de dependencias en él. Se trata de Slackdeptrack, un programa en modo comandos y que devuelve la salida como html, xml y graphvic.
Puede descargarse en el siguiente enlace.

Compártelo

Comiezo el nuevo año con nuevos propósitos y nuevos proyectos.
Dando un pequeño impulso a mi lista de todo’s he rescatado el proyecto “Embajadores Slackware“, cuyo fin es la realización de documentos que puedan ser después utilizados para dar a conocer nuestra distribución favorita a no iniciados en diferentes foros: charlas, irc, presentaciones, eventos, etc.

Para la mejor coordinación del proyecto he creado una pagina en el wiki de OpenSlack, que será el foco de actuación del mismo. Sobra decir que todo slacker con ganas de colaborar es bienvenido.

URL: http://open-eslack.org/wiki/index.php?title=Embajadores_slackware

Compártelo

Parafraseando a la definición de la Wikipedia “VMware es un sistema de virtualización por software. Un sistema virtual por software es un programa que simula un sistema físico (un ordenador) con unas características hardware determinadas. Cuando se ejecuta el programa (simulador), proporciona un ambiente de ejecución similar a todos los efectos a un ordenador físico (excepto en el puro acceso físico al hardware simulado), con CPU (puede ser más de una), BIOS, tarjeta gráfica, memoria RAM, tarjeta de red, sistema de sonido, conexión USB, disco duro (pueden ser más de uno), etc…”

VMware Workstation es el producto ideal para crearnos nuestras maquinas virtuales en el PC. Resulta que me registro en la web oficial(recordemos que VMware Workstation no es OpenSource), descargo el tar.gz y me lanzo a probarlo en mi Slackware. La instalación debería ser sencilla, dos pasos o scripts de perl: vmware-install.pl y vmware-config.pl. El chasco me lo di cuando en las preguntas que hace el script de instalación puse los datos correctos para el inicio de mi slack, es decir, que no hay /etc/init.d sino /etc/rc.d y me saltaron varios errores en la instalación, que se quedaba colgada.

Consciente de que por licencia no se pueden modificar esos scripts pero si verlos(están escritos en perl) vi un par de cosas curiosas, la primera en el script vmware-install.pl:

{
@rcDirList = (‘rc0.d’, ‘rc1.d’, ‘rc2.d’, ‘rc3.d’);
} else {
@rcDirList = (‘rc.0′, ‘rc.1′, ‘rc.2′, ‘rc.3′, ‘rc.4′, ‘rc.5′, ‘rc.6′);
}

Como puede apreciarse está usando un array con una lista de directorios que en el inicio BSD(el de Slackware) no existen, ya que solo existe el “rc.d”. Es una lastima que una modificación tan simple no pueda realizarse por temas legales y hacer que funcionara perfectamente en nuestro Slackware.

En el script de configuración vmware-config.pl también hay incompatibilidades con el inicio BSD:

sub updateInitdir {
my $dir;
my $initDir = “”;
my $initDirRoot = “”;
my $temp_dir;
my $instDir = db_get_answer(‘INSTALLDIR’);
my %patch;
$initDir = db_get_answer(‘INITDIR’);

Como podemos apreciar la variable initDir obtiene su nombre de una función, cuando en el inicio BSD debería ser simplemente “/etc/rc.d”. Una lastima que tampoco podamos modificar este script por cuestiones legales.

Para rematar la faena y que VMware Workstation funcionara en Slackware habría que modificar(el personal del vmware por supuesto) el script de inicio que por defecto es vmware por rc.vmware y alguna minucia más que ahora mismo no recuerdo. Lo que si sé es que VMware Workstation funciona de lujo en mi distribución de linux favorita , tal como podéis ver en estos pantallazos, tengo dos maquinas virtuales, una con Fedora Core 5 y otra con Windows XP Proffesional:

Un saludo

Compártelo