Microsoft August 2012 Black Tuesday Update - Overview

Published: 2012-08-14
Last Updated: 2012-08-14 18:49:46 UTC
by Rick Wanner (Version: 1)
12 comment(s)

Overview of the August 2012 Microsoft patches and their status.

# Affected Contra Indications - KB Known Exploits Microsoft rating(**) ISC rating(*)
clients servers
MS12-052 Cumulative Security Update for Internet Explorer - Layout Memory Corruption Vulnerability
(Replaces MS12-037)
MSIE
CVE-2012-1526
KB 2722913 No publicly known exploits. Severity:Critical
Exploitability: 1
Critical Important
MS12-053 Vulnerability in Remote Desktop Could Allow Remote Code Execution
(Replaces MS12-036)
Remote Desktop
CVE-2012-2526
KB 2723135 No publicly known exploits. Severity:Critical
Exploitability: 2
Critical N/A
MS12-054 Vulnerabilities in Windows Networking Components Could Allow Remote Code Execution
(Replaces MS08-067 MS09-022)
Windows Networking
CVE-2012-1850
CVE-2012-1851
CVE-2012-1852
CVE-2012-1853
KB 2733594 No publicly known exploits. Severity:Critical
Exploitability: 1
Critical Critical
MS12-055 Vulnerability in Windows Kernel-Mode Drivers Could Allow Elevatin of Privilege
(Replaces MS12-047)
Windows Kernel Mode Drivers
CVE-2012-2527
KB 2731847 No publicly known exploits. Severity:Important
Exploitability: 1
Important Important
MS12-056 Vulnerability in JScript and VBScript Engines Could Allow Remote Code Execution
(Replaces MS11-031)
JScript and VBScript
CVE-2012-3408
KB 2706045 No publicly known exploits. Severity:Important
Exploitability: 2
Critical Important
MS12-057 Vulnerability in Microsoft Office Could Allow Remote Code Execution
(Replaces MS11-073 MS10-105)
Office
CVE-2012-2524
KB 2731879 No publicly known exploits. Severity:Important
Exploitability: 3
Important N/A
MS12-058 Vulnerability in Microsoft Exchange Server WebReady Document Viewing Could Allow Remote Code Execution
Exchange
CVE-2012-2525
CVE-2012-1767
CVE-2012-1773
KB 2740358 No publicly known exploits. Severity:Critical
Exploitability: 1
N/A Critical
MS12-059 Vulnerability in Microsoft Visio Could Allow Remote Code Execution
(Replaces MS11-089 MS12-031)
Visio
CVE-2012-1888
KB 2733918 No publicly known exploits. Severity:Important
Exploitability: 1
Important N/A
MS12-060 Vulnerability in Windows Common Controls Could Allow Remote Code Execution
(Replaces MS12-027)
MSCOMCTL.OCX
CVE-2012-1856
KB 2720573 No publicly known exploits. Threatpost indicates being actively exploited. Severity:Critical
Exploitability: 1
Critical Critical
We will update issues on this page for about a week or so as they evolve.
We appreciate updates
US based customers can call Microsoft for free patch related support on 1-866-PCSAFETY
(*): ISC rating
  • We use 4 levels:
    • PATCH NOW: Typically used where we see immediate danger of exploitation. Typical environments will want to deploy these patches ASAP. Workarounds are typically not accepted by users or are not possible. This rating is often used when typical deployments make it vulnerable and exploits are being used or easy to obtain or make.
    • Critical: Anything that needs little to become "interesting" for the dark side. Best approach is to test and deploy ASAP. Workarounds can give more time to test.
    • Important: Things where more testing and other measures can help.
    • Less Urgent: Typically we expect the impact if left unpatched to be not that big a deal in the short term. Do not forget them however.
  • The difference between the client and server rating is based on how you use the affected machine. We take into account the typical client and server deployment in the usage of the machine and the common measures people typically have in place already. Measures we presume are simple best practices for servers such as not using outlook, MSIE, word etc. to do traditional office or leisure work.
  • The rating is not a risk analysis as such. It is a rating of importance of the vulnerability and the perceived or even predicted threat for affected systems. The rating does not account for the number of affected systems there are. It is for an affected system in a typical worst-case role.
  • Only the organization itself is in a position to do a full risk analysis involving the presence (or lack of) affected systems, the actually implemented measures, the impact on their operation and the value of the assets involved.
  • All patches released by a vendor are important enough to have a close look if you use the affected systems. There is little incentive for vendors to publicize patches that do not have some form of risk to them.

(**): The exploitability rating we show is the worst of them all due to the too large number of ratings Microsoft assigns to some of the patches.

--
-- Rick Wanner - rwanner at isc dot sans dot org - http://namedeplume.blogspot.com/ - Twitter:namedeplume (Protected)

12 comment(s)

Comments

I'm a bit confused about the MS12-060 regarding MSCOMCTL.OCX. That it is very common component used by older 3rd party applications and it looks like it is only updated if I have one of the software packages mentioned in the http://support.microsoft.com/kb/2720573. For example on one computer the MSCOMCTL.ocx was updated but COMCTL32.OCX was not. The comctl32 would be updated if I had Visual Basic 6 IDE (which I did on another environment). What if I did not have any of the software packages mentioned in kb2720573 but still had the MSCOMCTL.OCX installed by 3rd party application? Would I still be vulnerable (I would think so).
Microsoft's position is that unless the OCX/DLL got on to your computer from a supported Microsoft product, patching that file is the responsibility of the vendor that redistributed it. Yup. Have fun.

Also, they updated something like 29 OCX/DLLs in the April Runtime release and they set killbits for a whole bunch of older OCX/DLLs in that release as well, which implies they either know or suspect there are vulnerabilities in the older files. That one also also only installs if you have the VB6 IDE installed. BTW, they did document MsStdFmt.ocx in the April bulletin and mention that you can killbit while you wait for your 3rd-party vendors to knock down your door with updates, but didn't document the other 27 files (probably because they weren't reported by external sources).

Personally, I think this almost rises to the level of irresponsible disclosure on Microsoft's part.
So, is there any way for force installation of the April bulletin and the latest one on our systems?
And did anyone else notice they snuck an exchange security update into a rollup update? No? Well, here you go: http://blogs.technet.com/b/exchange/archive/2012/08/14/released-update-rollup-4-for-exchange-2010-service-pack-2.aspx which includes this one: http://support.microsoft.com/kb/2740358. Significance being this will not show up if you only do critical/security updates via WSUS; it will only show up if you include rollup packs/service packs in your WSUS configuration.
I found a posted reg file to set the kill bit for the vulnerable tabstrip active-x in the August ms bulletins. It also says that the server-based IE running in Enhanced Security Mode is not vulnerable, for what that's worth, and if I understood it correctly. I think we're going to see more and more of these unfixed vulns, ms's way of getting us off the old products ie: "unsupported product". Actually, I think one can't really blame them, as much as we hate it.
This is not a new position on Microsoft's part. I first noticed this back in December 2008. One workaround (besides hammering on the scores of vendors who are behind the redistribution of these OCX/DLLs) that does work is authoring an MST to dike around the logic in the MSI that looks for the VB 6 IDE - you'll also want to dike out all the table entries that are VB 6 specific, and just leave the OCX installation and self-registration. It's not that hard if you're comfortable in Orca or the MSI editor of your choice.

But that's of questionable legality. Another approach is to use a machine with the VB 6 IDE on it to author an install that includes all of the patched OCX/DLLs and then you should be legally clean distributing that to all of your machines.

Of course one problem with all of these approaches is that there's no support from Microsoft for scanning. So you've got one of two alternatives. The easy one is to deploy all of the OCX/DLL files in that bundle and put procedures in place to ensure that they don't get overwritten. That defends you against later installation of a 3rd-party app that redistributes an older version, unless it installs it somewhere other than system32. The second approach is to write your own scanning and patching system from scratch just to handle these files. In either case, have fun! I'll try to post a complete list of the files you want to look for later today.
Thanks for that. We've had a look today for versions of MSCOMCTL.OCX on some systems today to get an idea of if we can find out if this file is lurking anywhere. We found it on a number of systems in the system32 / SysWOW64 directory, and in one particular programs directory. Which is nice.

None of these versions (system directory or otherwise) have been patched by this tranche of updates.

Which is also nice.
My bad. Actually, even if you tell your WSUS to not download rollup packs and the like, because RU4 for Exchange 2010 SP2 has a security update in it, apparently Microsoft has helpfully pushed it out with the other patches. Never mind me, apparently we're all getting that rollup whether we want it or not...
Here's a quick command line for scanning for those potentially out-of-date OCX/DLLs:

for /F "delims=" %i in ('dir /S /A /B /ON C:\*.ocx C:\*.dll ^| findstr /I "\comct232.ocx \comctl32.ocx \comdlg32.ocx \dbadapt.dll \dbgrid32.ocx \dblist32.ocx \mci32.ocx \msadodc.ocx \msbind.dll \mschrt20.ocx \mscomct2.ocx \mscomctl.ocx \mscomm32.ocx \msdatgrd.ocx \msdatlst.ocx \msdatrep.ocx \msdbrpt.dll \msdbrptr.dll \msflxgrd.ocx \mshflxgd.ocx \msinet.ocx \msmapi32.ocx \msmask32.ocx \msrdc20.ocx \msstdfmt.dll \mswinsck.ocx \picclp32.ocx \sysinfo.ocx \tabctl32.ocx"') do @ dir "%i"

If you have filever.exe installed and substitute it for the last dir, you'll get something like this:

--a-- W32i DLL ENU 6.0.98.16 shp 170,080 02-16-2010 comct232.ocx
--a-- W32i DLL ENU 6.0.98.34 shp 617,816 05-02-2012 comctl32.ocx
--a-- W32i DLL ENU 6.1.98.16 shp 155,984 02-16-2010 comdlg32.ocx
--a-- W32i DLL ENU 6.1.98.16 shp 57,168 02-16-2010 dbadapt.dll
--a-- W32i DLL ENU 5.1.98.13 shp 567,104 02-16-2010 dbgrid32.ocx
--a-- W32i DLL ENU 6.1.98.16 shp 222,528 02-16-2010 dblist32.ocx
--a-- W32i DLL ENU 6.1.98.16 shp 215,880 02-16-2010 mci32.ocx
--a-- W32i DLL ENU 6.1.98.16 shp 134,976 02-16-2010 msadodc.ocx
--a-- W32i DLL ENU 6.1.98.16 shp 84,808 02-16-2010 msbind.dll
--a-- W32i DLL ENU 6.1.98.16 shp 1,029,968 02-16-2010 mschrt20.ocx
--a-- W32i DLL ENU 6.1.98.16 shp 659,264 02-16-2010 mscomct2.ocx
--a-- W32i DLL ENU 6.1.98.34 shp 1,070,152 05-02-2012 mscomctl.ocx
--a-- W32i DLL ENU 6.1.98.16 shp 119,616 02-16-2010 mscomm32.ocx
--a-- W32i DLL ENU 6.1.98.16 shp 278,352 02-16-2010 msdatgrd.ocx
--a-- W32i DLL ENU 6.1.98.16 shp 252,240 02-16-2010 msdatlst.ocx
--a-- W32i DLL ENU 6.1.98.16 shp 206,160 02-16-2010 msdatrep.ocx
--a-- W32i DLL ENU 6.1.98.16 shp 340,800 02-16-2010 msdbrpt.dll
--a-- W32i DLL ENU 6.1.98.16 shp 328,512 02-16-2010 msdbrptr.dll
--a-- W32i DLL ENU 6.1.98.14 shp 258,880 02-16-2010 msflxgrd.ocx
--a-- W32i DLL ENU 6.1.98.16 shp 443,488 02-16-2010 mshflxgd.ocx
--a-- W32i DLL ENU 6.1.98.16 shp 136,008 02-16-2010 msinet.ocx
--a-- W32i DLL ENU 6.1.98.16 shp 151,376 02-16-2010 msmapi32.ocx
--a-- W32i DLL ENU 6.1.98.16 shp 178,512 02-16-2010 msmask32.ocx
--a-- W32i DLL ENU 6.1.98.16 shp 190,800 02-16-2010 msrdc20.ocx
--a-- W32i DLL ENU 6.1.98.16 shp 129,872 02-16-2010 msstdfmt.dll
--a-- W32i DLL ENU 6.1.98.17 shp 126,800 02-16-2010 mswinsck.ocx
--a-- W32i DLL ENU 6.1.98.16 shp 100,160 02-16-2010 picclp32.ocx
--a-- W32i DLL ENU 6.1.98.16 shp 80,208 02-16-2010 sysinfo.ocx

If you have any present files that are older, you've got an issue. All of those files have killbits in either the December 2008, April 2012, or Aug 2012 VB6 Runtime updates.
I ran all the updates from Windows Update (and double checked that no updates were offered afterwards) on a Windows XP with Visual Basic 6 IDE installed. MS012-060/MSCOMCTL.OCX was NOT updated.

When I ran the KB2708437/"Microsoft Visual Basic 6.0 Service Pack 6 Security Rollup Update" manually the file was finally updated. Scary..


Diary Archives