Bugs et noyau

Vu que généralement avec ce genre de sujets on va vite gloser sur les vulnérabilités d'Internet Explorer et défendre le modèle de sécurité supérieur de Linux, je vous laisse apprécier la petite histoire de Brad Spengler (mainteneur de grsecurity) postée sur bt. A mon avis cela montre deux choses: il n'y a pas vraiment de prise de conscience sécurité dans le noyau Linux. Et ensuite que le modèle "bazar" de Torvalds - "distribuez vite et souvent " , je cite Eric S. Raymond - ne convient pas trop à des kernels sécurisés à leur sortie (je parle bien des toutes dernières versions du noyau).

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.