Microsoft Patch Tuesday – three fixes for March, one critical, all ring coding alarms

It’s Microsoft Patch Tuesday again. For March 2011, there are only three patches to worry about.

Technically speaking, all of them could result in remote code execution – meaning that you might inadvertently run software not already officially installed on your PC – but only one is rated ‘critical’ by Microsoft.

Furthermore, SophosLabs has rated all three of these patches at ‘medium’.

None of the them has yet been exploited in the wild, and none of the vulnerabilities can be exploited merely by tricking you into browsing to a remote location.

This month’s patched bugs are as follows.

* MS11-015 is rated ‘critical’ and fixes two vulnerabilities classified as
CVE-2011-0032 and CVE-2011-0042.

This fix deals with two problems. They are shipped as one fix because both of them affect the Windows Media subsystem. The first is a DLL load-order bug; the second is a file parsing flaw which can be triggered when you open a Microsoft Digital Video Recording (.dvr-ms) file.

To explain: a DLL load-order bug happens when software that loads a DLL (a special sort of Windows program) at run-time isn’t careful enough about how it loads that DLL. Unfortunately, and insecurely, Windows always includes the current directory in the executable path – the list of directories in which the OS searches for programs you try to use. Worse still, it always searches the current directory first.

So, if your code loads a .DLL (or launches an .EXE file) simply by giving the name of the file, rather than an exact path – MYLIB.DLL, for example, instead of C:\MYCODE\MYLIB.DLL – Windows will first look for MYLIB.DLL in the current directory.

If your current directory is somewhere insecure – such as a user-writable local folder, a network share, or a remote WebDAV directory (which might even be off-site) – an attacker can Trojanise MYLIB.DLL by creating a malicious alternative version in the insecure folder, from which Windows will load it instead of the official DLL. If the Trojanised DLL then takes the trouble to load the official one, you will probably be unaware that the trickery has happened, since everything will otherwise work as usual.

A file parsing flaw is even more serious, since simply persuading or tricking you into opening a deliberately malformed file may force the vulnerable application to misbehave in exploitable ways. Attackers don’t need to drop an infectious DLL first and then lure you into the now-infected directory. They can send you an innocent-looking file by any means, e.g. email, web or USB key, in a format you’d reasonably assume to be data-only, yet infect you when you open it.

The file parsing vulnerability, which brings you one step closer to potential infection than a load-order bug, is the reason why this fix is labelled ‘critical’.

* MS11-016 is rated ‘important’ and fixes the vulnerability classified as
CVE-2010-3146.

This is a DLL load-order bug in Microsoft Groove 2007. (This product turned into Microsoft SharePoint Workspace 2010, which isn’t vulnerable.) If you’re a Groove user, this patch is for you.

* MS11-017 is rated ‘important’ and fixes the vulnerability classified as
CVE-2011-0029.

This is yet another load-order bug, this time in the Windows Remote Desktop Client. Which sysadmin amongst us doesn’t rely on the RDP Client on a regular basis?

But what can this month’s Patch Tuesday teach sysadmins about Windows security in general? Here are my take-aways:

* Just because a software vendor ticks the Security Development Lifecycle (SDL) box doesn’t guarantee that its software is safe. (Not that I am against an SDL approach. It’s worked well for Microsoft and many others. But it isn’t a panacea.) If your company develops software, and you have an SDL bureaucracy, don’t treat it as anything more than a framework for security. It isn’t security itself.

* Audit your own code today – all of it! – for DLL load-order bugs. Get penetration testers to look for them, too. These are egregious faults which always open the door, albeit sometimes only very slightly, to unauthorised tampering with your network. But they are often overlooked, because they rarely cause noticeable failures which might draw your attention to them.

* Insist that your vendors have a ruthless policy on DLL load-order bugs. They should regularly be carrying out step 2 above. (I know what you’re dying to ask. Yes, we do!)

* Use Server Core on any Windows server you possibly can. Even if that means splitting an existing server in two, or into two virtual machines, consider it. None of this month’s vunerabilities apply to the core OS itself. It took the community years to persuade Microsoft that a GUI-free core would be good for security. In 2008 they finally delivered, so take advantage of it.

* If you have a hacktivistic bent, email Microsoft and ask it to remove – or to provide an option to remove – the current directory from the Windows executable path, for all types of executable file.