Security design: Why UAC will not work

Pinning all your end-point security hopes on UAC assumes that criminals are not as smart as they really are

It's security's dirty little secret: Not having your users logged in as root or administrator will not stop malware.

There is a huge public security thrust to ensure that users are not constantly logged on with highly privileged access. In Microsoft Windows, this means not being logged in as a member of the administrators group or any of the other 17 groups with admin-like privileges (for example, Power Users). In Unix/Linux/BSD, this means not being logged in as root or bin or whatever else is close. In the AS/400, it means not being logged in as Qsysop or Qsecofr. For mainframes, it might mean superuser, terminal 0, or another user label indicating special privileges.

Unfortunately, the concept of least privilege is more a popular mantra than a rule in most environments. This is especially true at home, but it's nearly as bad at work. If you want to find someone logged in as administrator or root all the time, point your finger in the general direction of network security folks: "Do as I say, not as I do."

Microsoft is trying to encourage users and developers to go least privilege by introducing UAC (User Account Control) in Windows Vista, and the Unix/Linux/BSD folks have being trying for a decade longer with Switch User (SU).

No panacea

The problem is that even if no one ever logged in as a superuser, it wouldn't make a dent in the ability of malware writers to do bad things to us and our computers.

It would stop a lot of the current malware, but only because they are designed (like a lot of today's legitimate software) to expect the user running it to be logged on as privileged. And in most cases, this is a good assumption. Most users are logged in using privileged accounts, but malware doesn't need privileged access to do bad things.

Even today, there are hundreds of malware programs that can do all the nasty things they want: modify your computer, steal your identity, whatever, without ever needing admin or root access.

Forget for the moment remote buffer overflows, social engineering, phishing, and all the other sorts of maliciousness that don't care about your logon credentials; malware doesn't need to modify your system files to cause problems.

On location

It's always been a mystery to me why Windows malware tries so hard to modify files or place itself in the System32 directory. Most people say it's because the malware wants to modify the Windows OS, and that's true. But the System32 directory location isn't needed. I've been keeping a table of all the ways and places that Windows malware can locate itself to cause damage, and I have more than 130 entries. My Linux/Unix/BSD list is much smaller, but contains a few dozen locations. Many of the listings on both documents do not require admin or root access to manipulate.

For example, most Windows malware modifies the HKey\Local_Machine\Software\Microsoft\Windows\Run registry key, but I have dozens of other keys that can be modified to launch just as easily. For instance, malware can use the user's own registry profile keys instead. Users always have Full Control to their own profile's auto-run registry keys, and they are checked (and the listed programs launched) by the computer after executing code in the machine's startup areas.

Let me be more explicit: There is nothing that malware can do today that can't be done without privileged access. I'm not talking about the way they can modify the system, but the intended result of the modification. Malicious hackers may not be able to modify System32 or sbin, but they can still intercept your identity and steal all your money, without modifying your operating system or (in the case of memory-resident-only malware) a single file.

Show Comments