Soon after writing my last blog post on the potential security vulnerability to autonomously disable Windows 7 beta’s UAC system, I had realized that flaw was just one piece in a string of dominoes that fell much earlier when the new tiered-UAC system was introduced in Windows 7.
In summary, a second UAC security flaw in the Windows 7 beta’s default security configuration allows a malicious application to autonomously elevate themselves to full administrative privileges without UAC prompts or turning UAC off. A result I’m sure cannot be classified as “by design”.
This public disclosure comes after a private disclosure to Microsoft and Windows 7 beta testers earlier this week. Whilst Microsoft has not officially responded, I’ve heard rumors it may already fixed in current internal builds. If and until a patch is available, I feel obliged to outline the elevated risk (pun) to the millions of Windows 7 beta user running Windows 7 beta in its default UAC policy of “notify me of changes by program, not of Windows changes” which does not adequately enforce the privilege system, arguably an essential factor to a safe operating system.
Without going into too much detail, as you already may know from the previous postings, Windows 7 has the ability automatically elevates Microsoft-signed applications and code which specifies “auto elevation” to mitigate the number of UAC prompts. Rafael Rivera has more details how this works.
The fundamental risk with the above behavior is the fact that Windows is a platform that welcomes third-party code with open arms. A handful of these Microsoft-signed applications can also execute third-party code for various legitimate purposes. Since there is an inherent trust on everything Microsoft-signed, by design, the chain of trust inadvertently flows onto other third-party code as well. A phenomenon I’ve started calling “piggybacking”.
To demonstrate, one of the many Microsoft-signed applications that can be taken advantage of is “RUNDLL32.exe”. With a simple “proxy” executable that does nothing more than launch an elevated instance of “RUNDLL32” pointing to a malicious payload DLL, the code inside that DLL now inherits the administrative privileges from its parent process “RUNDLL32” without ever prompting for UAC or turning it off.
For more technical details about this and a downloadable proof of concept, head over to Rafael’s site where he has prepared a non-malicious informational executable and DLL rolled into one neat package to try for yourself at home.
Unfortunately this flaw is not just a single point of failure. The breadth of Windows executables is just too many and too diverse, and many are exploitable. The only solution I can think of is also one I don’t think Microsoft will even consider, that is to revert to a single UAC policy and prompt for every elevation including Windows’ own applications. I’m curious how this will play out.
Important: The advice to every Windows 7 beta user is to set your UAC setting to “high”. This will make sure granting privileges are only in the control of your own mouse clicks and should prevent a malicious application from exploiting this and the previous flaw. Again, the balance between usability and security comes under the spotlight.
In Microsoft’s defense, some people have also argued UAC is not a “security boundary”, a vague term in my books. I argue because UAC is designed to enforce privileges (processes cannot jump to any privilege they want) and control privileges (prompts for privilege changes) it is a security feature. If a security feature can be maliciously and silently bypassed or turned off, I would consider that a security flaw.
Finally, to clarify my perspective on the whole issue, Windows 7 is a great operating system and these UAC issues are just two particular cases in a very small list of notable issues. I disagree with how Microsoft had handled the original issue but I’m sure with the wider public feedback it received we will end up with a more secure operating system as a result. In no part am I trying to “derail” Windows 7’s success run, but ensuring the default security policy is adequately safe for current and future users.
Update: As it turns out, Microsoft had known of this Windows 7 UAC auto-elevation flaw all the back in November of 2008. “For Beta, Windows components that can execute arbitrary code and or apps (eg CMD, CSCRIPT, WSCRIPT, PowerShell, etc) are prevented from auto-elevating.” I guess they overlooked things then.
Update 2: Microsoft’s Jon DeVaan has posted a response on the official Windows 7 blog with an extensive look at the UAC system in Windows 7 and their decision on the default security policy. In conclusion, they continue to stand by their decision and does not indicate they will change the default UAC policy.
If the 
