UPDATED: Misleading and Incomplete Information in MS06-015

UPDATE APRIL 21: In response to reports of compatibility problems with the new extension verification component (verclsid.exe) of the MS06-015 update, Microsoft plans to issue a revised version of MS06-015 on Tuesday, April 25th. The updated update will effectively whitelist four extension class IDs. These are associated with HP Share-to-Web and some NVIDIA software.

Microsoft’s original workaround, as provided by Mike Reavey and documented in the KB article, only addresses one of the two compatibility problems. If you have the problems described in Microsoft Knowledge Base Article 918165 after applying the update and the previous registry fix did not work for you, I’ve provided two registry scripts that may help alleviate these issues.

The registry scripts are based on information from the newly-revised MS06-015 as well as the aforementioned article. It is worth mentioning that these registry files have only been tested for correctness, as the population base affected seems to be fairly low. If you can, wait for Microsoft’s re-release of the MS06-015 patch on April 25th. If you have issues with the application or compatibility of either of these, let me know, but by using them, you do so at your own risk.

The download locations are:

My PGP key is available from the MIT key server (pgp.mit.edu). You may retrieve it via the web.

You are encouraged to back up the relevant hive of the registry (or the entire registry, if possible) before making these changes. This will minimize downtime in the event of an unforeseen compatibility problem. You may find more information on how to backup the registry in Microsoft Knowledge Base articles 322756 (Windows XP and Windows Server 2003) and 322755 (Windows 2000).

Microsoft’s Patch Tuesday has struck again. It seems, that in order to enjoy Microsoft’s recent patch days, one must really appreciate the oh-so-sweet smell of downplay.

Today was no exception. Today’s downplay of the month goes to MS06-015. That bulletin announced a patch which supposedly plugged a single “Windows Shell Vulnerability” involving the shell’s handling of COM objects. It states, rather paradoxically:

When this security bulletin was issued, had this vulnerability been publicly disclosed?
No. Microsoft received information about this vulnerability through responsible disclosure.


Note The update for this vulnerability also addresses a publicly disclosed variation that has been assigned Common Vulnerability and Exposure number CVE-2004-2289.

According to a VIM post by Steve Christey, this vulnerability has been known since May 2004. So, let me get this straight. The vulnerability that is documented was privately-reported, but the “variation” that was also patched has been publicly known for 700+ days. In that case, the issue that is truly the “variation” is the issue that was discovered and reported privately after the public disclosure. At least, that’s how I hope it went down. Regardless, the information as published is extremely misleading and Microsoft’s choice not to document a publicly-reported vulnerability is not one that will be for the benefit of its customers’ security.

More interesting, is this convenient phraseology in MS06-015. The update includes two “changes to functionality”, one of which is below:

This security update includes a Defense in Depth change which ensures that prompting occurs consistently in Internet zone drag and drop scenarios.

Oh, and do tell us, Microsoft, what threat is this meant to address, exactly? The implicit statement the bulletin makes is rather clear: prompting in internet zone drag and drop scenarios was previously inconsistent. That’s not exactly rocket-science to anybody, and in fact, it sounds suspiciously like an attempt to plug the vulnerability I reported publicly in February, which is CVE-2005-3240. Now, without testing that hypothesis, I will refrain from passing immediate judgment or speculating on the likelihood of that possibility. The bottom line is this: we just don’t know.

Microsoft needs to be much more transparent about the real nature of the threats customers are facing. Microsoft doesn’t patch phantom vulnerabilities that don’t exist or unrealistic science-fiction attack scenarios. Microsoft’s under-documentation of these vulnerabilities leaves those charged with deploying patches in a tough spot. You simply don’t know what the patches are for. It’s virtually impossible to make a determination about a deployment timeframe if not deploying a patch has the potential to place you at an additional, unknown risk. As a result, administrators may deploy patches unnecessarily, erring on the side of caution (and risking compatibility problems in the process), or they may choose not to deploy based on incomplete information. Individuals making these kinds of decisions deserve better information.

Everytime Microsoft seems to be getting the security pitch right, one gets thrown in the dirt. Microsoft needs a new ball. MS06-015 should be revised or completely rewritten, with the objective of providing sensible, coherent and complete information to customers.

Message-Rendering Vulnerabilities in E-mail Readers

Richard Smith posted the following in a message to funsec this morning:

I’ve got some sort of bad email message in my POP3 inbox which Outlook 2003 is refusing to download. I’m not sure what the problem is with the message, but Outlook is complaining that it doesn’t have enough memory to process the message. See the attached screen shot.

However, I am now stuck because I can no longer read email from this account. I suspect the message is a spam message, so there are maybe other people in the same boat.

For the specific error message, see the screenshot from Richard’s report.

I have a copy of the original message, and can attest to the fact that it is severely malformed. The interesting part, however, is that the malformation does not appear to be what is to blame in this instance.

The recipients list on this particular e-mail contains hundreds of different e-mail aliases, and that appears to be what is causing problems. Outlook, in particular, appears to exhaust a limited-size heap when faced with such an e-mail message. The impact of that upon Outlook is quite severe, because messages aren’t removed from mail servers unless they are successfully written to the Outlook Inbox. This process fails when such a message is received due to the heap-exhaustion problem, and thus, the e-mail message remains on the server indefinitely. Outlook proceeds to re-download the message and fail to process it until it is deleted from the mail server where the attacked mailbox is hosted by some other means.

I’ve tried manual importation of local copies of the message into several mail readers and only one (Outlook Express) handled this in a semi-correct fashion unless the recipients list had been significantly shortened. The others all failed the import operation, but otherwise respond normally. It remains to be seen whether these clients can be caused to fail in a similar fashion to Outlook. At this point in time, I recommend filtering e-mail with exceedingly large recipient lists in the To or CC fields (say, 100 or more) and asking users to send such e-mails to large groups via blind carbon copy.

As I conduct more aggressive tests on other mail readers, I’ll post my results here.

Oracle Secure Search: The World’s Greatest Paradox?

A colleague of mine once used a term that seemed very fitting to a particular security process. He termed it what it was, in my opinion: a disgrace. That’s hard to say seriously without immediately thinking of the company that has, in the security space, re-defined what it means to be a disgrace: Oracle.

Further, Larry Ellison has also provided us today with a re-definition of what it means to be in denial. Speaking of Oracle’s as-yet-unfinished Secure Enterprise Search product, Ellison says:

We have the security problem solved. That’s what we’re good at, and that’s the hard part of the problem.

I’ll allow you some time to recover. I sure needed it.

Newsflash, Larry: repeating it ten thousand times doesn’t make it true, and it doesn’t bode well for you that you appear to believe your customers are stupid. You have security solved about as well as most of your industry did five years ago.

And by the way… what planet/drug are you on? It seems like a nice, carefree place. You’ll have to show me around sometime.

If Oracle is good at security, I’d really hate to see something they’re not good at. Oracle’s “security process” today is the unquestioned laughing-stock of the entire software industry, and is a justification of lousy practices elsewhere. Whenever I ask tough questions about timelines and other continual problems at other shops, I hear: “Hey, don’t look at us! We could be like… Oracle.”

Oracle’s developers write and ship the buggiest software in the history of the human race and are, apparently, often at a loss for how to even fix their inenumerable screw-ups. This is evidenced by delays of hundreds of days (several years in the worst cases) , only to find fixes of such high standards of quality that they cause huge breakages in their attempt to fix hundreds of different flaws. The sad thing? These broken patches are probably the only good ones Oracle ever developed. We’ve seen so many reports of Oracle’s patches failing to fix the targeted vulnerability that such reports are taken as ordinary. If you can’t secure it, breaking it so badly that the vulnerable code is no longer functional is the cheap way out.

Further, now we’re supposed to believe that Oracle has security “solved” and that its customers are filled with joy by monstrous CPUs with hundreds (or thousands) of vulnerability fixes, with only about a 10% chance (or less) that the fix will actually work?

More perplexing is one more significant question: people are actually buying this?

It’s amazing that Oracle’s “Unbreakable Linux” campaign has made such a business of crap-peddling. I really don’t understand their success. After all, if any other commercial software vendor were to claim its software was unbreakable (especially after Oracle’s mockery of the term) it would likely draw a lot of gut-busting laughter and be out of business shortly thereafter. Somehow, Oracle has survived with only one of the two.

With as much success as Larry’s had in software, I’d love to see him move this unbreakable Linux campaign to stand-up comedy. I’m sure he’d have some wicked ratings.

Windows Media Exploit: Lesson Learned Yet?

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.

2) prioritization

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.