Hola,
Como habréis notado he respetado el título original del artículo ya que creo que cualquier intento de traducción estropearía un titular que me parece -además de divertido- adecuado.
Os dejo este interesante paper de Rafal Wojtczuk de Invisible Things Lab, y lo hago por tres razones: la primera es ilustrar cómo un problema serio puede ser resuelto de una manera rápida, consensuada y al gusto de todos los implicados. El 17 de Junio Rafal notificó el problema al equipo de X.org. Tres días más tarde se decide que el problema debe ser discutido con los desarrolladores del kernel de Linux, ya que la manera adecuada de solucionar el problema pasa por parchear el núcleo. El 13 de Agosto Linus Torvalds resuelve le problema con el correspondiente parche, y ayer día 17 de Agosto se publicó este documento.
La segunda razón es dar a conocer el problema. Se trata de una vulnerabilidad descubierta accidentalmente y que al menos está presente desde la introducción hace unos 5 años de la rama 2.6 del núcleo de Linux. Es un problema con consecuencias extremadamente graves, ya que permite la elevación de privilegios a root desde procesos sin privilegiar que tengan acceso al servidor X, si bien no se explota problema alguno en X.
El problema puede ser explotado si un atacante modifica maliciosamente una aplicación que haga uso del servidor (cualquier aplicación con frontend gráfico, por tanto) siendo posible que se logren sobrepasar los mecanismos de seguridad provocando que el proceso corra como root, lo que técnicamente es un compromiso total del sistema. Según se explica en el documento, mediante este ataque es posible escapar incluso del afamado sandbox -X de SeLinux. Casi nada.
El problema se puede solucionar bien parcheando el núcleo (2.6.35.2 y 2.6.34.4 están libres del problema), bien deshabilitando la extensión de intercambio de datos de imágenes entre el cliente y servidor empleando la memoria compartida (MIT-SHM). Tenéis más información de este interesante caso en el blog de Joanna Rutkowska y los detalles del problema están narrados con detalle en el documento Exploiting large memory management vulnerabilities in Xorg server running on Linux.
Sí, efectivamente, tienes razón: eran tres las razones, y me he reservado la última para el final. El tercer motivo es pensar sobre cuántas vulnerabilidades similares a esta estarán aletargadas entre las millones de líneas del código de Linux. Probablemente muchas, y probablemente la mayoría no están siendo explotadas activamente, si bien tener certeza de esto es imposible. Aunque Linux es un sistema extremadamente eficiente, estable y seguro, no sólo hay esqueletos en los armarios de Redmond. Sirva este ejemplo para ilustrarlo.
Un saludo,
Oye, se te ha olvidado decir que son los tipos más rápidos del mundo haciendo las pruebas, los tests de regresión, despligue, actualización, etc… Vamos, en ese tiempo no soy capaz yo de probar una aplicación de mierda. Enhorabuena por la velocidad en hacer las pruebas con todos los entornos donde pueda afectar ese cambio en el kernel.
Saludos Malignos!
Traducción libre y resultona «Linux: un muerto en el armario» :-)
Sergio ¿qué opinas del parcheo que ha hecho Torvalds?
Además de haberlo hecho con agosticidad y alevosía, es decir, sin avisar propiamante, el parche en sí mismo ha sido fuertemente criticado.
Popotxo,
Si me preguntas como Sergio Hernando, usuario de Linux en casa, te diré que no tengo ningún problema con el parche, ya que es claro, simple y solventa la papeleta. La mayoría de los usuarios ni se enterará, y serán las distribuciones las que se encarguen de elevar la versión del núcleo.
Si me preguntas como Sergio Hernando, usuario de pago de una solución Linux soportada por un hipotético tercero, pues te diré que para mí el problema no es lo que haga Linus, es lo que haga mi proveedor de Linux con el producto que me soporta. Es el tercero el que me pasa facturas y me ofrece soporte, no Linus. Por tanto tampoco me supone problema alguno lo que haga o deje de hacer Torvalds en sus commits. Por ejemplo, mira Red Hat –> https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2010-2240
El parche en sí es sencillo, apenas unas pocas líneas y mínimamente invasivo (http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=320b2b8de12698082609ebbc1a17165727f4c893#patch1) y yo la verdad no entiendo la naturaleza de las críticas en esta ocasión. Esto es código abierto, al que no le guste o convenza lo que haga Linus o cualquier otro desarrollador del kernel en un diff, pues que lo haga a su manera. Y sin el menor de los problemas, oiga. Al menos podemos ver claramente qué hace, con lo que estamos en condiciones de escoger si seguir su camino o no. Y la licencia nos permite hacer los cambios :)
¿Críticas? Quizás el parche no sea todo lo elaborado que se pueda. Cierto. Si miras el código verás que básicamente Linus lo que ha hecho ha sido asegurar que cuando se llena la primera página del segmento de pila, se hace crecer el segmento una página, lo que evita el agotamiento. El mismo admite que quizás sea mejor tener un procedimiento de expansión manipulable, por ejemplo, dejando escoger el número de páginas de guarda que se quiera tener, pero comenta que se debe atajar el problema empleando la solución simple en primera instancia. A los que no les guste pueden modificar el código a su antojo para paginar como les de la gana :)
Un saludo,
Maligno,
Los desarrolladores del kernel no suelen tener tanto miedo de que tocar 7 líneas de código en el núcleo acabe jorobando las aplicaciones de los clientes, como sucede en otros sistemas operativos. Es una de las ventajas de tener una buena segregación entre el espacio de usuario y el núcleo.
No le pidas a los desarrolladores que hagan el trabajo que tienen que hacer los que soportan las soluciones, que son los que le cobran a los clientes. Y si eres un usuario que no emplea una versión soportada, pues mira, esto es Linux, comprende lo que tienes entre manos, asume que el soporte, si no lo obtienes de una compañía, es DIY y si no te gusta te compras un iPad o te instalas un Windows 7.
Saludos !
Muy buen articulo , y muy buenas respuestas (con argumentos) las que les has dado a popotxo y al maligno chema. Sigue asi.
Saludos.
Gracias Sergio por tus opiniones :-)
Sergio, lo de las 7 líneas me ha encantado. ¿Es eso una medida? Tocar 1 línea (y si no que se lo digan al amigo del SSH de Debian) puede ser muuuuuuuuy crítico.
En cuanto a la frase esa de: «Es una de las ventajas de tener una buena segregación entre el espacio de usuario y el núcleo» es para que repasemos juntos – un día entre dos – el Windows Internals y alguna charla de M. Russinovich. }:))
En mi humilde opinión, creo que un parche así, debería haber estado en manos de las Distros para hacer pruebas mucho antes de que se hiciera público para que salgan los exploits. Pero… es lo que tiene el full disclosure, por eso a mi me gustaría algo más elaborado..
Saludos my friend!
Sergio:
Muy buen artículo y muy buenas las referencias.
Y las respuestas a las dudas, perfectas. Por este tipo de cosas, sigo con Linux.
Saludos.