The Microsoft security team is constantly in the news, either responding to security concerns or patching known vulnerabilities. And at every step of the way, we in the IT industry must walk between skepticism and trust when it comes to accepting and deploying these patches. Thankfully, there are a number of respected researchers, who spend untold hours pouring over code and evaluating scenarios simply to expose vulnerabilities or validate patches. One such researcher is Thor Larholm, who maintains an up-to-date list of patched and unpatched security holes in Microsoft's Internet Explorer.
Patrick Mueller: The debate in the security community surrounding full-disclosure, while somewhat abated in recent months, is still a source of strong opinions. Meanwhile the possibility of consensus on the issue among leading analysts seems nearly impossible. You seem to follow what most would call a policy of "responsible disclosure" by notifying the vendor and allowing them time to produce a patch. Do you follow specific "rules of engagement" for disclosure, such as Rain Forest Puppy's RFPolicy? How did you derive your rules, or are they dynamic based on the situation?
Thor Larholm: My own approach to disclosure is very fluid and depends largely on the severity of the vulnerability as well as the vendor response, though I much prefer to act "responsibly." Ideally, I would like to follow the guidelines in RFPolicy, with clear and agreed responsibilities by both parties. In the past I have tried both delayed disclosure, while the vendor was fixing the vulnerability, as well as premature disclosure, in particular when Netscape conned GreyMagic Software and I disclosed 2 additional holes. In the latter case, a vendor notification would have been futile. I decide on a set of rules in the days following vendor notification, based on their preliminary response.
Patrick: Microsoft products continue their long history of serious security vulnerabilities in everything from operating systems, to backend applications, to web browsers. However, during the past six months, Microsoft has begun to pledge a new dedication to security, including the announcement that they were ceasing programming for a full-month in order to devote the time to auditing code for security vulnerabilities. Is this an empty promise of the Microsoft PR machine, or will we see higher-quality code (from a security standpoint) rolling out of Redmond in the coming years?
Thor: I doubt that we will see any real improvements in the current generation of products. Security is not any single product or project, it's an approach and a process. So far [Microsoft's] efforts have amounted to discovering a few undisclosed holes in its products and making a great deal of fuzz. Whatever it is that they have taught their horde of programmers remains to be seen, as it is now they are barely keeping up with their own patches. They need to redesign fundamental aspects of their software infrastructure, and until that has been done, all we will see is workarounds and preliminary patches. Bottom line: everything is the same for now but their intentions are promising..
Patrick: In the past, Microsoft has been accused of systematically downplaying, denying, or otherwise avoiding alleged security issues in their products. Several in the security community recognize that while the more important underlying, technical issues of insecurities and the product development process that create them are still in place, Microsoft's reaction to security researchers and vulnerability disclosure has finally matured -- for example, crediting researchers in their advisories, producing timely patches, and a more forthcoming approach to the problem are mentioned.
What has been your experience in dealing with the Microsoft security team?
Have you noticed any differences in your Microsoft dealings in the past several years (i.e. trends)?
Thor: My experiences with the Microsoft security team has been pleasant so far. We may disagree on release dates and vulnerability severities, but the tone has always been very respectful and thankful. They seem to learn from their mistakes and are willing to change policies over time. That said, I don't think anything has changed in particular on timely patch delivery - bearing in mind that there is currently (May 12) 14 unpatched security vulnerabilities in Internet Explorer (http://jscript.dk/unpatched ). They are also not quite in favor of full disclosure or even preliminary public notification of vulnerabilities that are being researched. Sometimes they seem to prefer that their customers remain exploitable for months instead of agreeing with the researcher on a preliminary publication including temporary workarounds.
As for trends, they are becoming increasingly responsive. It is my hope that at some point they may even follow RFPolicy, especially with regards to notifying the researcher regularly on the status of the issue - I have had to poke them some times to find out whether anything was being done.
Patrick: In your opinion, which security vulnerability that you've discovered is the highest risk for real-world exploitation by malicious hackers? Please explain, and give scenarios if possible.
Thor: In my opinion, the dialogArguments vulnerability would seem like the highest risk for real-world exploitation. It removes the barriers that are ordinarily in place when dealing with location-based authentication. Using it with foreign sites enables you to steal cookies (e.g. hijacking a Hotmail account) or impersonate the user (e.g. purchasing bogus orders with Amazon OneClick). When used to circumvent port boundaries it becomes possible to circumvent e.g. SSL and eavesdrop on otherwise encrypted communication. If used to delude foreign protocols you can inject arbitrary script in local zones, [for example,] leading to privilege escalation and arbitrary command execution (to name a few). It's also a vulnerability that remains to be patched, and [it] is already being actively exploited in the wild. The latest [exploit] I saw was a nimda-like worm using it in combination with its built-in webserver to automatically execute the payload.
Patrick: The vulnerability you discovered in the dialogArguments functions are essentially a cross-site scripting (CSS) issue. While CSS is a somewhat nebulous "vulnerability," we continues to see CSS advisories on a regular basis in everything from small open source web-based projects to products from major vendors, including Microsoft and Novell. While theoretically devastating, the level of real-word exploitation is largely unknown, and apparently, relatively low (or at least severely underreported). How serious are CSS attacks from a "real-world" risk analysis standpoint?
Thor: From a "real-world" risk analysis [perspective], most CSS issues can be categorized alongside with the classic man-in-the-middle attacks. They enable arbitrary persons to act on either the servers or clients behalf, changing the information sent either way as seen fit. My personal estimate would be that CSS issues are currently of Low severity, but that they have the possibility of rapidly becoming a High severity if they were to be realistically exploited on a larger scale.
Patrick: Fixing CSS vulnerabilities is a gargantuan undertaking since there are so many components: web servers, web browsers, end user configuration, and custom developed server-side code. Leaving aside custom-developed code, applying effort to fix which component will affect the greatest benefit to mitigating the CSS risk overall?
Thor: Web servers are historically the ideal location for any CSS vulnerability to be found, when looking from the perspective of a malicious hacker. Their installation base may be far outnumbered by web browsers but their effective period of exploitation remain exponentially larger - staying connected 24/7 with a high probability of either remaining unpatched or easily detected by version numbers. They represent a stable base for exploitation whereas web browsers and custom-developed code present too many variables that need to be taken into account. As such, malicious hackers are more likely to exploit CSS vulnerabilities in web browsers and the greater effort should be applied here.
