RHEL, kernel vulnerabilities, and days of risk [LWN.net]

RHEL, kernel vulnerabilities, and days of risk

Posted Mar 25, 2005 8:08 UTC (Fri) by khim (subscriber, #9252)
In reply to: RHEL, kernel vulnerabilities, and days of risk by giraffedata
Parent article: RHEL, kernel vulnerabilities, and days of risk

Ahh, good old "Security Through Obscurity" argument. It does work this way for small-scale systems (something like 10 or 100 installations). It does not work this way for widely deployed systems like Linux and Windows.

"Black hats" do have incentive to find and use holes in Windows, "white hats" do not (what good will it do if you can not even ask for patch and doing it yourself is out of question?).

Since most security problems are found in Linux with code auditing it's usually not exactly clear how to exploit hole at all for a long time but Windows holes are only ever acknowleadged when exploit is shown: there are still unpatched holes with obvious "buffer overflow crash" symptoms going back to NT 4.0 - but since exploits and not flying around Microsoft can claim "it's not a security problem - it's a feature".

So in effect you are not having a system with a "bugs that are a closely held secret" but rather you are having a system with a "bugs that are not widely exploited yet" - quite a difference.

(Log in to post comments)

RHEL, kernel vulnerabilities, and days of risk

Posted Mar 28, 2005 17:35 UTC (Mon) by giraffedata (subscriber, #1954) [Link]

Those are all good points about security, but don't address the topic of this thread: whether the days of risk measurement in this study is a valid measurement for comparing security risk among programs.

The article suggests that some bugs have an unfairly low days of risk measurement. The bugs you describe that are not a closely held secret, but just not widely exploited, would have a high days of risk measurement. So they're not the ones we're talking about.

Also, I don't think whether Microsoft acknowledges a bug is part of the measurement. But one could imagine that the study biased the measurement by looking only to the easy sources -- Microsoft announcements -- to find out when bugs became known. That would make the issue moot.