Security Information Vulnerability Research Security Blog

Linus: Full Disclosure? Sure. Partially.

July 17th, 2008 by , Filed under: Commentary, Culture, Full Disclosure

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.

Share
  • anon

    Slashdot has picked this one up. Will be curious to see what happens here.
    http://it.slashdot.org/it/08/07/17/1242220.shtml

  • Pingback: Josh's Blog

  • Wade Stuart

    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.

  • http://www.BeyondSecurity.com Aviram

    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.

  • anonymous

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

  • Share







  • Categories


Security RSS Subscribe