Out-of-band security patch addresses critical Windows vulnerability

It's a part of Windows that handles all the file and print sharing services over any network. Today, Microsoft decided to take the unusual step of issuing a patch for a vulnerability on this part now, and not wait until November 11.

The part of Windows known as the Server service -- the component responsible for handling file sharing, print sharing, and pipelining between computers -- has been hit once again with an exploit whose profile resembles an August 2006 problem patched the following month. But this time, Microsoft is announcing it received information about this latest exploit privately, indicating that unlike the older incident, Microsoft was working to pre-empt any possibility of the exploit making its way into the wild.

A patch is already being issued, just over two weeks from Microsoft's usual Patch Tuesday release period. Though it could have remained silent for another few weeks, the company chose to act now.

Essentially all versions of Windows are affected by this vulnerability, including those patched by service packs, and including all versions of Vista and Windows Server 2008 -- for x86, x64, and Itanium-based systems. Everything made this decade with the "Windows" brand requires this patch.

Just as before, the list of services that could be affected by this latest hole, is astounding. Most importantly, anything that relies on Server Message Block (SMB) including the Common Internet File System (CIFS), any kind of file or print sharing, remote group policy enforcement, the print spooler, the indexing service, and network logon -- all of these are among the items impacted by a potential hijacking of the Server service. Essentially, anything that need sharing or to be shared goes through the SMB protocol, which is managed by the Server service.

Exactly how an exploit would manage to gain control of the SMB protocol in this instance has not been revealed, for obvious reasons. Microsoft's vague description essentially says that a maliciously crafted remote procedure call from a source that is authenticated as the Server service (it has to be authenticated first) can trigger a situation where arbitrary code can then be executed without authentication.

In lieu of applying the patch, Microsoft's suggested list of workarounds is not pretty. For instance, for Vista users, the company advised that the Windows Firewall is a very handy tool for turning off visibility of one's computer -- effectively removing it from even a local network. For admins, Microsoft details how they can write filtering rules that effectively eliminate any traffic from services that have been authenticated as the Server service.

A check of the UID of that service -- the key used to authenticate it -- reveals a long history of not just exploits, but attempts at exploits. In 2006, it was learned that when a component places a remote procedure call using the authenticated Server service interface, the stub that's returned -- in COM-speak, the handle of what's being requested -- contains way too much data. Included to that data was an open pointer to the heap, that remote components should not have.

In early Microsoft security models, the way COM traffic was passed was by authenticating the interface through which it was passed, under the theory that it wouldn't be using the interface unless it had permission to do so. In the Component Object Model, an "interface" is more like a logical template through which data is passed; anything read through the interface takes the form specified by the template, which is pointed to in the System Registry. So in short, the presumption was if a component could use an interface, it was probably because it should.

That security model has long since been deprecated; but in the interim, Microsoft has found itself struggling to overcome the security assumptions created by the old COM way of "remoting." If today's exploit is similar, a private security researcher (thus far uncredited) may have discovered yet another way to use the unnecessary bounty of information a stub can return when an RPC is placed using SMB protocol.

There does not appear to be evidence that a working exploit is active and in the wild at this time, though based on what evidence BetaNews did turn up today, one could be close.