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
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.