Well, it's the second Tuesday of the month, a day that I affectionately refer to as 'Black Tuesday'. Today is the day that Microsoft unleashes their latest set of patches and system administrators scramble to apply them, but this time around, we have a twist. After three straight months of some of the most voluminous (I looked it up, it's a word) Microsoft security advisories, they've finally taken a break. In June, we had to deal with 12 advisories, in July they settled on 7 and in August, the bar was once again set at 12. What did they give us in September? Three advisories encompasing three vulnerabilities. That's it? Don't get too excited, based on what I see in the queues or other researchers (e.g. ZDI), there are plenty more to come, Microsoft just seems to be taking a quick breather.

Below is a quick cheat sheet on the vulnerabilities that were just released. If you're headed into a meeting with the big boss and need to rattle off a few quick facts, go no further. If you're looking for insight on each of the issues, continue onto the narratives following the chart.

MS06-052

Vulnerability in Pragmatic General Multicast (PGM) Could Allow Remote Code Execution

There is a remotely exploitable vulnerability in the pragmatic general multicast (PGM) protocol, which is a component of Microsoft Message Queuing (MSMQ). What is PGM and why would you need it? Good question. PGM is a TCP based reliable multicast protocol, meaning that it includes loss detection information and leaves it to the receiving node to determine if all packets have been successfully received. Interestingly, the IEEE still deems this to be an experimental protocol.

There are two pieces of good news here. First, only Windows XP (SP1 and SP2) is vulnerable. Second, MSMQ is not enabled by default. As for the bad news...while, if you are running MSMQ, no authentication is required in order to trigger the vulnerability. Microsoft has rated this issue to be of an 'Important' severity despite the fact that remote code execution is possible. While that's a relatively rare stance for Microsoft to take, it has presumably been done due to the fact that the service is not enabled by default on any vulnerable machines.

The vulnerability was discovered by David Warden, who does not have a history of publishing Microsoft vulnerabilities so at this point we have no reason to believe that exploit code or a third party advisory is forthcoming.

MS06-053

Vulnerability in Indexing Service Could Allow Cross-Site Scripting

This vulnerability is a bit difficult to understand without an understanding of the Indexing Service, so let's start there. The indexing service is an operating system resource that can be used to facilitate faster searching in much the same way that a tool such as Google Desktop would be used. It creates catalogs that are binary databases of content found and by default, it will create a System catalog for searching the file system and a Web catalog for searching IIS web applications.

The details of possible exploitation scenarios are sketchy at best but from the discussion of the potential workarounds, exploitation appears to take the following form. A victim running a vulnerable instance of the Indexing Service would be social engineered into visiting a website which contains malicious client side script which is encoded using a Unicode format. That script would cause a query to run against the local Web catalog and due to the XSS vulnerability, the client side script would execute on the local machine. This could result in information leakage as data could then be sent back to the malicious website. Significant mitigating factors are the degree of social engineering involved along with the lack of default machines running the Indexing Service.

This is not the first time that the Indexing Service has run into problems. MS00-084 disclosed another XSS vulnerability, while MS05-003 detailed a vulnerability that resulted in remote code execution.

MS06-054

Vulnerability in Microsoft Publisher Could Allow Remote Code Execution

Microsoft continues to be dealing with a steady stream of file format vulnerabilities and we're beginning to wonder if they'll ever go away. This particular issue was outstanding for 402 days from the time that it was first reported to Microsoft, according to the original researcher. If true, that's a concerning statistic as no amount of regression testing should take a year to complete.

Past Microsoft Office file format vulnerabilities have been favorites for malicious code authors and we can expect this one to be no different. The researcher has stated that it's a fairly straightforward stack based overflow which would suggest that public exploit code won't be far behind. One mitigating factor for this vulnerability versus other Microsoft Office issues is the fact that Publisher is only included in Professional versions of Microsoft Office, so it's not as widely deployed as products such as Word and Excel. Organizations with Publisher 2000 deployed should pay particular attention to this vulnerability as that version of publisher does not provide the end user with a warning message prior to opening a Publisher file, when one is downloaded from the web. This patch may also cause some compatibility issues as is prevents older Publisher 2.0 files from being opened.

Don't expect this to be the last that we see of file format vulnerabilities in Microsoft Publisher. While researching this issue, I ran a very basic *.pub file through a file format fuzzer and found literally dozens of unique crashes. While it will take further research to determine if these are exploitable, the sheer volume of exceptions found was enough to suggest that this is not a particularly secure format.