we’ve been hearing a lot about software distributors downplaying vulnerabilities in their code. it seems like a familiar tune. sunshine’s post hits on it. i talked about it two weeks ago after mozilla managed to (yet again) severely downplay some trivially-exploitable vulnerabilities fixed by recent patches. judging from this week’s windows media player fiasco, the lesson hasn’t been learned.
accurate assessment is important for two reasons:
1) adequate coverage
if those responsible for deploying fixes are led to believe that vulnerabilities are of less risk than is actually present, this means that systems that need to be protected, aren’t.
exhibit one: the microsoft internet explorer dom race condition vulnerability. microsoft was informed of the potential issue more than six months before it was proven to be exploitable. because of a bad risk assessment on microsoft’s part, most of its user base was tactically naked when code appeared demonstrating the exploitability of the issue.
if issues that aren’t of severe risk are rated as such, the risk assessment system being used implictly has less merit. over-hyping can force affected customers to look for other sources of information about risk (which may not always be coherent) or to do costly risk assessment of their own before deploying fixes to evaluate potential damage to compatibility in the face of a security issue of uncertain risk. of course, that also increases the possibility that the customer will make the wrong choice.
accurate risk assessment (particularly from vendors) clearly is of importance to creating conditions that lead to a secure user base. it should be obvious, then, why researchers as a community (as a result of a predisposition toward that goal) are generally willing to take extreme measures to ensure that an accurate risk assessment is achieved. the rest of this post is an example of what not to do if you get an assessment wrong.
during an exchange with microsoft’s security response center about the recent windows media plug-in vulnerability (ms06-006), i was very sharply critical (no pun intended) of the weak ‘important’ rating given to this vulnerability. i pointed out several facts:
* firefox installs windows media support implicitly
* windows media is installed on almost all windows pcs
* the vulnerability could be triggered simply by viewing a web page in an alternate browser with the plug-in enabled
* a vulnerability with a very similar trigger that was exploitable from ie was rated ‘critical’
the answer i received was that were a scenario developed where a component that was “installed by default” could be exploited without anything more than a click for interaction, the vulnerability would probably be upgraded to a critical severity. the only sense in which the vulnerable code is not a “default install” is the fact that alternative browsers aren’t present on most fresh installs of windows. nor are office, frontpage, iis, or any other of a myriad of components… and that doesn’t preclude vulnerabilities in them from receiving ‘critical’ ratings.
i pointed to the above and offered some clarification. essentially, i see no reason this vulnerability shouldn’t be rated ‘critical’. i’m then told that, had the msrc believed it possible, such a scenario would clearly justify a ‘critical’ rating.
so… the exploit in front of me is impossible?
that was the last straw. i had a few details to work out, still. my exploit hadn’t really been fine-tuned and so was a bit unstable in the “real world” environment. msrc, however, had just given me the impetus to make it stable. in my effort to bring about a bit of sanity in the impact assessment, i released proof-of-concept code that demonstrated exactly how easy it is to exploit an alternative browser on a system without ms06-006 applied.
oddly enough, microsoft has left its rating alone. and not for good reason. now, we have two exploits available and users are still being kept in the dark about how serious this vulnerability really is. this issue is a critical risk and has been from day one. microsoft should demonstrate to its user base that it understands this and give the vulnerability the rating it deserves. at least, if users must be exposed to threat, they should have accurate information about what that threat really is. not using your company’s browser is not a reason to be kept in the dark.