Barrapunto

El fallo no es de X.org, es del kernel, en la gestión de memoria compartida. Si me equivoco decidlo.

Te equivocas, pero también se equivoca HispaSec, se equivoca Slashdot, y hasta Rutkowska dice equivocada -y seguramente de forma interesada- cosas como que "se salta todas las protecciones modernas de Linux" -específicamente SELinux sigue funcionando tal y como está diseñado-.

El fallo es de X.Org, y no del kernel. Es muy sencillo: el modelo de memoria del núcleo y de la gran mayoría de sistemas operativos definen el uso de una pila (para variables locales, alloca(), etc) y de una heap (para malloc(), mmap() y otros), que crecen en sentidos diferentes y el uno hacia el otro.

Ni el kernel ni ningún otro sistema generalista ofrece ningún medio per se para impedir que ambos lleguen a sobrescribir la misma memoria.

Y el problema está en que X.Org ofrece una manera de incrementar el heap de forma arbitraria a petición y con contenido de un proceso no confiable hasta que llega a coincidir con la pila, permitiéndole a éste modificar direcciones de retorno al heap que él mismo controla, donde pondría su código que X.Org ejecutaría como root.

Ni SELinux tiene nada que ver, ni el kernel peta por ningún lado. ESTO OCURRE EN TODOS LOS SISTEMAS OPERATIVOS CON UN MODELO DE MEMORIA SIMILAR.

Simplemente X.Org ofrece un servicio sin proteger de este detalle, permitiendo a un cliente ejecutar código arbitrario: es el servidor X el que tiene el bug.

Otra cosa es que luego, sin ningún tipo de discusión y en un hack brutal, Linus haya decidido por su cuenta que quiere evitar esto forzando que el proceso que se encuentre en esta situación muera (mediante el mapeo de una página entre la pila y el heap).

O sea, que X.Org sigue siendo vulnerable con ese parche en el kernel, aunque ahora en lugar de ejecutar código arbitrario nos harán un DoS.

Y la solución propuesta hace 6 años por Andrea Arcangeli, basada en crear una interfaz para proteger de esto a los procesos que lo pidan con el fin de que no lo tengan que controlar ellos y obtengan la proteccion sin matar el rendimiento, es mucho mucho mejor. Pero ni hay obligación de hacerlo, ni nadie más lo hace, y desde luego no es un problema del kernel lo que un proceso haga con la memoria que tiene asignada.