Windows 7 'Security Flaw' Really Is By Design

Blogger Long Zheng is <a href="http://www.istartedsomething.com/20090130/uac-security-flaw-windows-7-beta-proof/">raising concern</a> about a supposed Windows 7 security bug that he discovered. He's shown that it is possible to push keystrokes into the User Account Control dialog to turn off UAC completely. Although Zheng contacted Microsoft about the problem, they insist it's "by design."

Dave Methvin, Contributor

February 1, 2009

5 Min Read
InformationWeek logo in a gray background | InformationWeek

Blogger Long Zheng is raising concern about a supposed Windows 7 security bug that he discovered. He's shown that it is possible to push keystrokes into the User Account Control dialog to turn off UAC completely. Although Zheng contacted Microsoft about the problem, they insist it's "by design."This has Zheng either outraged or concerned (or both) because this security hole appears to be headed to inclusion in Windows 7. But wait a minute; it's really easy to confuse yourself into thinking things are security holes when they're not. So I'm going to use a great blog entry from Mark Russinovich that dates back to 2007. That writeup is what set my mind straight on UAC and what it really is intended to do. Russinovich explains:

In Vista's integrity model, every process runs at an integrity level (IL) and every securable object has an integrity level. The primary integrity levels are low, medium (the default), high (for elevated processes), and system. The windowing system honors integrity levels to prevent lower-IL processes from sending all but a few informational window messages to the windows owned by processes of a higher IL, calling this protection User Interface Privilege Isolation (UIPI).

When running as an administrator on Vista, UAC shows you a relatively simple dialog asking whether you want to continue. It doesn't require a password or other authentication; all you need to do is click. You're already an administrator, after all, and Windows is just double checking that you really meant to run the program that's being run. If you run as a standard user, you will be prompted to enter an administrator password. Therefore, for the administrative user, UAC is just a really annoying "dear Administrator are you sure" mechanism and not a true security boundary. That is confirmed by Russinovich:

[Integrity Levels] do not define security boundaries. What's a security boundary? It's a wall through which code and data can't pass without the authorization of a security policy. User accounts running in separate sessions are separated by a Windows security boundary, for example. One user should not be able to read or modify the data of another user, nor be able to cause other users to execute code, without the permission of the other user. If for some reason it was possible to bypass security policy, it would mean that there was a security bug in Windows (or third-party code that allows it)

With that background in mind, here is the really, really, important point that Long Zheng missed:

Because elevations and ILs don't define a security boundary, potential avenues of attack, regardless of ease or scope, are not security bugs. So if you aren't guaranteed that your elevated processes aren't susceptible to compromise by those running at a lower IL, why did Windows Vista go to the trouble of introducing elevations and ILs? To get us to a world where everyone runs as standard user by default and all software is written with that assumption.

In other words, UAC was not intended to make it secure for a Windows user to run as an administrator. It was intended to stop the horrible practice of users running as an administrator, which is often required because XP-era applications automatically expect that kind of access. The same goes for all of Vista's magical remapping of unprivileged writes to common file and registry areas such as Program Files. Windows Vista (and now Windows 7) is trying to limit the damage that applications can cause while at the same time doing its best to prevent apps from breaking. These are more compatibility measures than security measures. Like a tourniquet around your neck to stop a nosebleed, it's not a good long-term solution.

Let's not forget that the UAC prompts have been one of the biggest annoyances that people mention about Vista, and even the butt of the joke in an Apple TV ad. That's why Windows 7 loosened the tourniquet a bit. Microsoft could put it back to Vista's strictness by default, but that has two possible bad outcomes. One, experienced users will become annoyed by UAC and disable it completely; about 20% of Vista users do this. Two, novices will get used to automatically saying "Yes" to any UAC prompt they see because they happen so often. I don't see how either situation improves security.

Remember as well that Internet Explorer has a Protected Mode which runs at the lowest possible rights level. Because of that, it wouldn't be likely that an IE-based exploit could silently disable UAC. It would take someone saving a file to the disk and clicking through the "are you sure you want to run this since it came from the Internet" prompt. In that scenario, the user knows they are running code that might not be trustworthy. Would a second prompt help? I doubt it.

The correct solution to this problem is clear: Don't run with administrative privileges during everyday work. I know that is often easier to say than to do, but two years of Vista being out there has helped to beat software developers into a mindset that they shouldn't assume the user is an administrator. If you are in a business setting, push back on software vendors that can't run their software in a standard user account. If you are using Vista at home, set up a standard user account and use it. If you absolutely insist on running Windows 7 as an administrator, turn UAC back to full-annoyance Vista mode and stop complaining.

About the Author

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like


More Insights