Only one of the bulletins is rated “Critical”: MS12-004, which is a vulnerability relating to Windows Media Player. Exploiting this vulnerability would allow remote code execution and this should be of top concern for both companies and private users. This vulnerability can be exploited by embedded malicious Windows Media Players in web pages. This should serve as a reminder that we should expect researchers and attackers to continue to exploit client applications such as media players and browsers. In fact, media players are the target of non-stop fuzzing: the process of throwing the kitchen sink at an application to find where it breaks.
Microsoft has also introduced a new category: "Security Feature Bypass". MS12-001 is the first bulletin to be classified this way and I doubt we’ll see this category used very often. Safe Structured Exception Handler (SafeSEH) is a technology introduced in Microsoft Visual Studio .NET 2003 and allows to protect the overwriting of Structured Exception Handler during exploitation. Binaries compiled with the /SAFESEH option with Microsoft Visual C++ .NET 2003 RTM creates a situation where the Windows Kernel can’t respect this protection.
In a perfect world the right way to fix issues like this would be to have every developer rebuild their binaries with the latest version of Microsoft Visual C++ .NET. This is impossible though as it would mean hundreds of developers would have to rebuild tons of legacy binaries. The great thing about this patch is that it mitigates attacks regardless of the version of .Net used, essentially modifying the way the Windows Kernel opts these binaries into the SafeSEH protection.
MS12-006 patches the SSL vulnerability which was scrapped last month, reportedly because of incompatibility issues with SAP. Microsoft and SAP were able to resolve the issues, and deploy the update this month. This pulled patch last month emphasizes the point that organizations need to test patches for compatibility before patching. In the case with SAP they have access to test these patches before deployment. Smaller software providers might not have access to the patches before Microsoft releases them. Organizations should alway test, then patch.