Historias
Slashboxes
Comentarios
 

Login Barrapunto

Login

[ Crear nueva cuenta ]

Draco (3721)

Draco
  (email no mostrado públicam.)

Down Kill Up Publicidad

Bitácora de Draco (3721)

Lunes, 10 de Enero 2005

Críticas a la seguridad en Linux

12:29h.
Kernel Linux

Cuando no hace ni una semana de que se diera a conocer una grave vulnerabilidad en Linux(que por cierto no ha aparecido en portada de barrapunto), uno de los desarrolladores de grsecurity se ha despachado con unas fuertes críticas relativas a la baja prioridad que se le da a la seguridad en el kernel. Creo que merece la pena leerlas, así que las pongo a continuación:

2) Linux Kernel advisory introduction

Let me begin by giving you a timeline:

December 15th: I send Linus a mail with a subject line of "RLIMIT_MEMLOCK bypass with locked stack" December 27th: The PaX team sends Linus a mail with a subject line of "2.6.9+ mlockall/expand_down DoS by unprivileged users" January 2nd: The PaX team resends the previous mail to Linux and Andrew Morton

Between December 15th and today, Linus has committed many changes to the kernel. Between January 2nd and today, Andrew Morton has committed several changes to the kernel. 3 weeks is a sufficient amount of time to be able to expect even a reply about a given vulnerability. A patch for the vulnerability was attached to the mails, and in the PaX team's mails, a working exploit as well. Private notification of vulnerabilities is a privilege, and when that privilege is abused by not responding promptly, it deserves to be revoked.

Using 'advanced static analysis': "cd drivers; grep copy_from_user -r ./* | grep -v sizeof", I discovered 4 exploitable vulnerabilities in a matter of 15 minutes. More vulnerabilities were found in 2.6 than in 2.4. It's a pretty sad state of affairs for Linux security when someone can find 4 exploitable vulnerabilities in a matter of minutes. Since there was no point in sending more vulnerability reports when the first hadn't even been responded to, I'm including all four of them in this mail, as well as a POC for the poolsize bug. The other bugs can have POCs written for just as trivially. The poolsize bug requires uid 0, but not any root capabilities. The scsi and serial bugs depend on the permissions of their respective devices, and thus can possibly be exploited as non-root. The scsi bug in particular has a couple different attack vectors that I haven't even bothered to investigate. Some of these bugs have gone unfixed for several years.

The PaX team discovered the mlockall DoS. It has been fixed in PaX for 2 years. I have attached their mail and exploit code.

I'd really like to know what's being done about this pitiful trend of Linux security, where it's 10x as easy to find a vulnerability in the kernel than it is in any app on the system, where isec releases at least one critical vulnerability for each kernel version. I don't see that the 2.6 development model is doing anything to help this (as the spectrum of these vulnerabilities demonstrate), by throwing experimental code into the kernel and claiming it to be "stable". Hopefully now these vulnerabilities will be fixed in a timely manner.

Este hilo ha sido archivado. No pueden publicarse nuevos comentarios.
Mostrar opciones Umbral:
Y recuerda: Los comentarios que siguen pertenecen a las personas que los han enviado. No somos responsables de los mismos.
  • Security Officer

    (Puntos:3, Informativo)
    por Unleashed (8472) el Lunes, 10 Enero de 2005, 15:12h (#419828)
    ( http://www.flawedcode.org/ )
    No es "uno de los desarrolladores de grsecurity", es el único desarrollador, Brad Spengler, conocido por su notable egocentrismo, por esperar a que saliera FC2 para liberar un exploit para el execshield, por sus contínuas batallitas de críos [wideopenbsd.org] con los desarrolladores de OpenBSD (algunos de ellos tampoco se quedan atrás) y por ser todo un hacha y haber creado grsecurity.

    En el anuncio de la versión 2.1.0 de grsecurity y de las vulnerabilidades descubiertas se incluye también un extracto de un mail reenviado varias veces por el equipo de PaX a Andrew y Linus, y se especifican los títulos de los mails.

    Sinceramente, con esos títulos y el volumen de correo que deben recibir esas personas, veo muy difícil que por mucho que se reenviaran los correos alguno pudiera llegar a ser visto.

    El problema que tanto Spengler como el representante de PaX dicen tener es que no saben a quien enviar estas cosas, un Security Officer oficial para Linux en el que se pueda confiar y se niegan a hacerlo a los contactos de seguridad de las distribuciones. Más aquí [lwn.net].
    --
    Unix have fun [barrapunto.com]
  • por runlevel0 (1932) el Martes, 11 Enero de 2005, 01:03h (#420123)
    ( http://www.flickr.com/photos/runlevel0/ | Última bitácora: Jueves, 01 Noviembre de 2007, 11:37h )
    Ya, pero la diferencia está en los lacitos:

    Aquí se queja un tipo que encima parece ser que cae mal por pesado y egocéntrico, y si sigues la línea de mensajes Alan y más gente ya están trabajando en ello.

    Sobre MS se quejan cientos de personas pero no hacen nada.

    Cada 'tropezón' del soft libre hace que este se haga más fuerte, sino fíjate en lo que ha pasado con el asunto SCO, del que Linux y el Soft Libre no sólo no han salido perjudicados, sino que ya cuentan con soluciones legales para este tipo de problemas.

    Todo esto se puede resumier en: "Hey tíos, a ver si areglaís esto de una puta vez""Vaaale", mientras que lo mismo en el caso de MS sólo da por resultado un "¿Mandeee? Ballmer, cierra las persianas que hay ruido".
    --

    29A the Number of the Beast
    [ Padre ]
  • 3 respuestas por debajo de tu umbral de lectura actual.