Ay, debian, debian...

Hoy sí que toca despotricar. Y nunca creía que llegaría este día, pero esta vez le toca el turno a ¡Debian! Siendo mi primer "Linux de verdad" y el que mas tiempo he usado (ininterrumpidamente desde la 3.0 en un server, casi 7 años ya) le tengo un especial cariño, pero parece ser que últimamente todo se está yendo a la mierda en un intento por ser user-friendly.

El tema es que en un portátil con openSuse, el NetworkManager dejó de funcionar, lo cual por cierto no hace más que confirmar mi opinión sobre el "programa". Dado que el usuario principal del portátil no tiene ni idea de informática y no va a tocar absolutamente nada aparte de encenderlo y "poner el Internet", el sistema a usar es prácticamente indiferente, con tal de que funcione y no se rompa (lo cual elimina Vista, cualquiera con NM y potencialmente XP, por temas de virus, etc). Dado que Debian hasta ahora había funcionado perfectamente siempre que lo había instalado y el equipo era bastante antiguo (3-4 años, Centrino con intel 2200bg), no lo dudé y fui a bajarme la imagen de instalación.

- Primer FAIL: para instalarlo con un pendrive hay que leerse el howto, un README en el ftp y bajarse dos archivos distintos: la imagen USB y... ¡una iso de instalación!
- Segundo FAIL: la imagen USB que ofrecen al escribirse en el pendrive, crea un sistema FAT de 256 MB en el disco raiz, es decir sin particiones. Luego hay que montar el disco (qué raro se hace escribir "mount /dev/sdb /mnt/dest" en lugar de sdb1) y una vez montado, copiar en el destino la iso.
- Tercer FAIL: Una vez arrancado, no detecta NINGUNA de las interfaces de red de un sistema de hace 3 o 4 años, a pesar de tener una opción en el menú que dice explícitamente "detectar interfaces de red".
- Cuarto FAIL: en el paso de "buscar iso de instalación", busca la iso de instalación. Lo cual es gramatical y semánticamente correcto, pero yo lo que esperaba es que además, ENCONTRARA la iso de instalación, que está en la raíz del pendrive con el que ha arrancado. Por alguna razón que no me explico, busca en todos los discos duros y particiones del ordenador, pero no en el disco de instalación, con lo que evidentemente no lo encuentra. Por supuesto, aunque la instalación era en "modo experto", añadir un botón de "indicar la ruta manualmente" en caso de no encontrar la iso, era muy complicado. No vaya a ser que alguna abuela se líe. Tristemente, la filosofía GNOME se extiende por el mundo. User-friendly que te cagas.

Resultado: mandar a la mierda el invento de Debian, arrancar openSuse, arrancar Yast, mandar NetworkManager al agujero de donde nunca debió haber salido y sustituir en "/etc/init.d/network" por un script de 3 lineas que levante la interfaz, la conecte a la wifi y arranque dhclient para configurarla. Elegante no es, pero "el Internet funciona", que era el objetivo inicial.

Random made in Debian

Es curioso como es posible meter la pata hasta el fondo con la mejor de las intenciones.

Allá por mayo del 2006 alguien decidió limpiar un poco la biblioteca openssl, usada para casi cualquier cosa relacionada con la seguridad en un sistema Linux. Pero aparte de la llamada que era errónea, se cargó también otra que era vital para la inicialización del generador de numeros pseudoaleatorios (PRNG). El proceso fue en resumidas cuentas, tal como:

• Versión principal usa ingeniosas chapuzas usando memoria no inicializada para obtener aleatoriedad.
• Versión principal usa el mismo código y los mismos nombres de variables para hacer otras cosas.
• Versión principal no usa comentarios para distinguir entre ambos.
• Responsable de mantenimiento pregunta en la lista de openssl-dev y obtiene una respuesta algo ambigua.
  
• Responsable de mantenimiento generaliza en exceso el cambio (y se carga ambas llamadas).
• El bug se le escapa a todos en el proceso de revisión.

Y tenemos cachondeo para rato. La parte seria del asunto es MUY seria, dado que las claves "aleatorias" que genera obtienen su aleatoriedad de uan sola fuente, el identificador de proceso. Y ya que generalmente esto son 15 bits (32k posibilidades) tenemos que en unos 20 minutos se puede adivinar la clave generada. Accesos SSH con claves de usuario generadas en sistemas vulnerables, certificados SSL, VPN's con secretos compartidos... todos ellos con un nivel de entropia de 15 bits. Terrorífico. Por suerte las sesiones SSL de los navegadores no se han visto afectadas, supongo que porque usaran GNUTLS o alguna otra biblioteca para generar las claves de sesion.

Para más info mirar en el DSA de debian o en el blog de Luciano Bello, el que descubrió el bug.

Para arreglar el problema basta con el clásico apt-get update && apt-get upgrade, que actualizará openssl a una versión parcheada y openssh invalidará las claves vulnerables y generará otras seguras. En la wiki de debian se puede consultar sobre la actualización de las claves de otros programas y leer algo sobre testeo y resumen técnico.

Y ya que hemos hablado de la parte seria, (y antes de eso, actualizado el server debian con acceso ssh) ahora toca el cachondeo:


Meta-incertidumbre


Incertidumbre certificada

Si no os habeis actualizado ya, ¡¿a qué esperais?!

Cronometrando la seguridad

Leo en barrapunto que distrowatch ha sacado una comparativa sobre el tiempo que le ha llevado a las principales distribuciones de linux arreglar el fallo de seguridad del kernel que permitia a los usuarios locales convertirse en root. También cuentan la historia del fallo, que por lo visto se descubrió y arregló el día 8 de febrero en las listas del kernel y la primera distribución en arreglarlo fue debian el día 11 a las 13:58.
Aunque ellos cuentan el tiempo como el transcurrido desde que se publicó la versión estable del kernel que corregía el problema (2.6.24.2) hasta que el cambio se incorporaba a la distribución, lo lógico sería contarlo desde el día que se conoció la vulnerabilidad, ya que desde el 8 en adelante los sistemas eran vulnerables a un exploit conocido de manera pública. De hecho distribuciones como Arch publicaron un parche el día 10, 1 día antes del parche oficial de kernel. Gentoo aparece como que se aviso el día 13, pero en la noticia se puede leer que las versiones parcheadas se subieron el lunes, día 11, así que entre dentro de las primeras 10 horas desde la publicación oficial.
Lo más grave me parece que distros como Ubuntu, la que mas usuarios tiene y Red Hat Enterprise, de pago y dedicada a entornos profesionales, hayan tardado mas de 1 día en arreglar el fallo. Y en el caso de Ubuntu, teniendo ya los parches masticaditos en los repositorias de Debian...

Seguridad en Debian

Si hay una cosa que me encanta de Debian es la facilidad de actualizarlo. Al comprobar los repositorios en busca de paquetes nuevos comprueba las actualizaciones de seguridad por un lado y las de versiones actualizadas por otro y lo muestra separado. Así se puede decidir si es necesario actualizar un paquete, instalando todas las actualizaciones de seguridad y de las versiones nuevas, sólo las que se consideren necesarias o útiles.

Pero todo esto me ha fallado/sorprendido con el reciente bug que salió para el kernel. Afectaba a casi todos los núcelos entre 2.6.17 y 2.6.24.1 inclusive (parece ser que los SELinux se salvaban) y aprovechaba un fallo en la función vm_splice para hacer escalada de privilegios: un usuario normal ejecutaba un programa especial y mágicamente se convertía en root. Naturalmente, para ello antes hay que tener acceso al sistema como usuario normal, así que no es aprovechable de manera demasiado sencilla. En el PC de casa se puede hacer, pero no se puede aplicar a un servidor remoto sin antes obtener una shell local con algún otro fallo de seguridad.

Como el server casero que tengo es basicamente servidor de archivos y router/firewall, no me di demasiada prisa por aplicar el parche, ya que en principio sólo hay 2 puertos expuestos a internet y confío bastante en las protecciones de ambos, así que era bastante difícil que alguien obtuviera shell para aprovechar el exploit. Además, con un uptime de bastante más de 50 días me daba pena reiniciarlo.

Había oído hablar del bug y del exploit, pero yo hacía apt-get update y no veía por ningún lado un aviso para instalar un nuevo kernel. Alguna otra aplicación si que salía de vez en cuando, así que los repositorios funcionaban, pero del kernel ni rastro. Me extrañó muchísimo con todo el tiempo que pasaba, ya que normalmente tardan pocas horas en sacar parches y no días, así que decidí buscar a ver si encontraba algo. Y efectivamente, ya había kernels nuevos, e incluso si los buscaba en aptitude salían, pero como versiones distintas, no como mejoras de seguridad, ni siquiera como actualizaciones del que usaba.

Supongo que la razón es para no cambiar el kernel en sistemas que hacen periódicamente un "apt-get update && apt-get upgrade". Cambiar el kernel puede ser peliagudo y como mínimo requiere reiniciar, así que no sería nada bueno que los sistemas lo hicieran ellos solos. Bueno, Vista sí que reinicia cuando a él le da la gana, pero al Vista hay que darle de comer aparte. Si bien está claro que cambiar el kernel de manera automática no es buena idea, lo que sí que estaría bien sería que apareciera algún aviso al hacer un update, un mensaje por consola o algo que avisara del peligro, quizá algún admin (sobre todo de sistemas caseros) no esté al tanto del problema y se quede con un sistema vulnerable.

Así que ya sabeis, haced un uname -r en una consola y si os da una versión entre 2.6.17 y 2.6.24.1, actualizad el kernel cuanto antes, que el fallo no es moco de pavo.