Linus: Full Disclosure? Sure. Partially.
July 17th, 2008 by Aviram, Filed under: Commentary, Full Disclosure, Culture
The linux kernel group would be the last group of people I would expect to support obscuring helpful messages in an attempt to improve security.
Brad Spengler says it well. You should read his entire message, but the punch line is this section:
They seem to have the impression that people who find an exploit kernel vulnerabilities rely on the commit messages fixing the vulnerability including some mention of security. As it should be clear to anyone actually involved in the security community, or anyone who has ever written an exploit (particularly for the myriad silently fixed vulnerabilities in Linux), this is far from reality. The people who *do* rely on these messages and announcements however are the smaller distributions and individual users. Yet Linus et al believe they’re helping you by pulling the wool over your eyes regarding the exploitable vulnerabilities in their OS.
I can’t say it better than Brad, so instead I’ll say it shorter: In Security, the more information becomes public, the more secure everyone is. There are very few exceptions to this rule.
-
Is your site safe from XSS Attacks? Use Active Network Scanning to protect your network!
Subscribe
Subscribe
Slashdot has picked this one up. Will be curious to see what happens here.
http://it.slashdot.org/it/08/07/17/1242220.shtml
Full Disclosure in the Linux Kernel?…
There has been a lot of squabbling about disclosing security issues, specifically in the Linux Kernel as of late.
This is probably getting a lot more attention than it should. There are two ways this can be dealt with.
1) Insist the bikeshed be …
Well, I do agree with Linus that the git changelog should not pinpoint the security related changes. This does not mean that a hand crafted Security notice should not be attached to the changelog for the release (This release fixes two security issues and should be installed on all systems), nor that distro’s should not have some sort of trusted email group that gets alerts about these changes (I believe they already do and it does get used to communicate these changes backchannel).
It is a balance of notifying with the least amount of damage to the install base by giving exploiters direct pointers to the code that was changed.
Wade, the whole issue is that exploiters *do* have direct pointers to the code that was changed. They have the time and they will put the effort required, and this is proven time and time again.
There is no real “balance” to think about, and by hiding the security implications it’s only the good guys that suffer.
“I can’t say it better than Brad, so instead I’ll say it shorter: In Security, the more information becomes public, the more secure everyone is. There are very few exceptions to this rule.”
Amen to that.
And amen to the absence of this so-called “balance”. If anything, advocating this kind of a “balance” will shift the focus from community-based distributions to commercial ones, those that have full-time employees tracking the issues — in both cases hopefully with as much information as is possible.