Windows 7's ability to selectively elevate privileges is under scrutiny

In Microsoft's ongoing effort to alleviate users' discomfort with Windows Vista's security nags, the company may be re-introducing a potential powder keg of new problems, as researchers continue to discover.

In his continuing investigation of the UAC bypasses being tested for Windows 7, developer Rafael Rivera points out another potentially serious problem: As developer Leo Davidson noted in a recent blog post, some binaries in Windows 7 are given the ability to present XML-based manifests of themselves that give themselves a privilege called autoelevate.

It does exactly what it sounds like it does. Now, in Vista itself, auto-elevation has also been possible, but on a very broad scale only. For example, it's technically possible for User Account Control to suppress all prompts to anyone logged in as an administrator; in fact, a freeware tool for just this purpose has been available since 2007. However, in Win7, an XML-based tag enables this privilege to be extended to individual programs.

Though online community support personnel may not always have direct communication with Microsoft engineers, an explanation given by support personnel member Jialiang Ge last month regarding a question a Win7 tester had after discovering this feature, is being dissected today by Rivera and others. Here is the section in question:

The change we made in Windows 7 default UAC settings is that any operation that is necessary to manage windows will not require an elevation - which in technical terms translates into a white list of trusted action / binaries which the user can make perform without UAC prompting from an elevation. This list does include windows file operations.

You see a prompt in your File Manager program because your binary is not an inbox binary - i.e. not an executable which ships with windows. Hope that explains and clarifies. For security considerations, Windows 7 does not allow any 3rd party binary to be in the Windows trusted list. Therefore, your File Manager program still needs to handle the elevations.

As Ge described it, although a white list does not physically exist, the list of all binaries whose autoelevate tag is engaged may as well be a whitelist. And while Microsoft has asserted that only Windows gets to decide which binaries belong to the whitelist -- or, more specifically, that the privilege of assigning the tag has been assigned only to Windows -- an example of a Windows binary that is frequently used by third-party utilities just to run (ever since Windows 3.0, in fact) has been RUNDLL32.EXE.

While this alone is not evidence of a potential security hole in the current Windows 7 beta, it can point to where such a hole is likely to develop. It all depends on how Microsoft chooses to treat the Windows binaries that can be shared by other applications produced outside of Microsoft.

Historically, components of Microsoft's Component Object Model, in use since the days of Windows/386, suffered from their inherent implicit trust in one another. That non-questioning attitude was what led to some of the original ActiveX security holes that led to the widespread discrediting of that technology.