For some reason Flash embedding seems to be disabled for G&C, so I'll have to link to a
that shows exactly how to launch any program with full administrator rights with no prompt, and without you even knowing it happened.
The changes Microsoft has made to Windows 7's UAC render it little more than a pesky annoyance. If this is the path the company wishes to go down, it should stop doing things by halves and kill it off altogether.
I wrote a few weeks ago about changes Microsoft has made to Windows 7's User Account Control (UAC) that make the component less secure than it was in Vista. Though the company has responded by saying it will change some of the problem behaviors, yet more problems have emerged that indicate that a real fix will be harder than first expected. But more than that, the flaws call into question the entire purpose of the Windows UAC feature, at least in its commonplace "Admin Approval" mode.
The decisions Microsoft has made not only make Windows 7's Admin Approval mode less secure than Vista's, they also undermine the entire purpose of the UAC system. Redmond maintains that UAC's foremost objective is to ensure programmers update their programs to behave properly when users have limited access rights. But the way that the Windows 7 UAC "improvements" have been made completely exempts Microsoft's developers from having to do that work themselves. With Windows 7, it's one rule for Redmond, another one for everyone else.
The combination of significant security flaws and the inconsistent, "Do as I say, not as I do" attitude towards UAC should give Microsoft pause for thought. There's no point in retaining Admin Approval mode as it currently stands, and it should be scrapped completely.
The new exploit, discovered and demonstrated here, depends on a third mechanism for elevation that was previously overlooked. The first mechanism for elevation is the traditional prompt—the user is notified that a particular program wants to elevate, and can permit or deny the request. The second is the auto-elevating executables described in my previous article, in which certain system executables automatically elevate without any notification. Chief among these is a program rundll32, which can load and run almost any DLL, and will do so fully elevated.
Microsoft may or may not fix the rundll32 problem; as it stands, it blows a big hole in UAC since it allows any software to trivially bypass the prompts, but since the change was made with the objective of removing prompts from "legitimate" uses of rundll32, the company has something of a dilemma: stop rundll32 auto-elevating and reinstate the prompts (thereby improving security), or keep the auto-elevation and ignore the security impact.
It may not matter much what Microsoft does with rundll32, however, as the newly demonstrated attack shows. The new attack allows an attacker to trick pretty much any auto-elevating program into running code of the attacker's choosing—even auto-elevating programs that aren't meant to run arbitrary code. It does this by exploiting other parts of Microsoft's auto-elevation system.
Overview of the new attack
Although a few programs in Windows 7 are always elevated, most are not. For example, the Explorer shell runs without elevation, unless the user explicitly opts to elevate it and verifies the UAC prompt. Nonetheless, there are Explorer tasks that require elevation that are common enough that Microsoft felt they should auto-elevate. The most common one of these is probably creating a folder in a protected location (in Program Files, for example). In the original Vista release, this activity would cause an annoying back-to-back double elevation: once to create the folder, and again to rename it to its intended name. Service Pack 1 streamlined this a little, reducing it to only a single elevation, but Microsoft clearly wanted to get this down to zero.
The technique that all versions of Vista and Windows 7 use to perform individual tasks with elevation (rather than running an entire program elevated) is to put the elevated action into its own component and to call that component from the main program. This is in fact the main way in which UAC support should be added to applications, because it generally requires less elevation than elevating entire programs. If the operation in question isn't even attempted, no attempt to elevate occurs either, which is obviously the best possible outcome.
This component-based technique is used for Explorer's file management operations in Vista and Windows 7. Creating, copying, moving, renaming, and deleting files all occur within a particular component that gets elevated when necessary, leaving Explorer itself unelevated. In Windows 7, however, Microsoft has made this component auto-elevating. So although Explorer itself cannot elevate automatically, it can create a component which can.
This component is quite limited—it can do a handful of file manipulation operations, but won't run arbitrary code—and even the auto-elevation is restricted. Auto-elevating components will only elevate when called from Microsoft-signed applications; if third-party code tries to use them, a UAC prompt will appear. On the face of it, this wouldn't be enough to compromise a system; third party code can't use the component to elevate, and even if the component is running, it can't be used to trivially run arbitrary code in the way that the rundll32 flaw can (although it could certainly overwrite or remove key system files, which might break the system).
Unfortunately, the "Microsoft-signed application" restriction is easily bypassed using a standard Windows trick that allows one process to insert code into a second process, as long as both processes are being run by the same user. The limitations of the file management component are probably unavoidable (it can only do the things it has been programmed to do, after all), but it turns out it doesn't really matter. The file management component can place files into various locations on the system that an unelevated user cannot; an auto-elevate program can then be tricked into loading those files and executing code from them.
The result is, just as with the rundll32 problem, silent and automatic elevation, able to do anything.
The implications
So, does any of this matter? Well, I think it does. Microsoft and its supporters have argued throughout that UAC in Admin Approval mode isn't a security boundary, and as such, escalation of this kind is not a security problem. Although Windows does have plenty of security boundaries—two users logged on at the same time should not be able to kill each other's processes or read each other's data, for example, because each session has a boundary around it—UAC is not one of them. What this means is that it doesn't really matter, in Microsoft's view, if people figure out a way to bypass UAC.
And indeed, in Vista there are ways for malicious programs to piggy-back off UAC elevations to get elevated themselves, and these haven't been fixed. There is, however, a big difference between how this plays out in Vista vs. Windows 7. In Vista, these workarounds still depend on the user at some point permitting a program to elevate, and the elevated program has to be the one that the malware has booby-trapped. In Windows 7, all the guesswork is gone; the exploitation is consistent and systematic.
Microsoft hasn't been entirely consistent in its stance on this matter. The company has bowed to public pressure over some of the Windows 7 UAC changes already, and reinstated more secure behavior even though this has meant reintroducing some UAC prompts. This move is inconsistent with the stated policy; after all, if UAC is truly not a security barrier, why bother making fixes whose only justification is the security they provide? However, the latest exploits appear to be essentially unfixable without wholesale reintroduction of the UAC prompts. Since the entire motivation behind the changes in the first place was to avoid these prompts, any solution that reinstates them is unlikely to fly.
Do as I say, not as I do
But the real crux of the issue is what this treatment of UAC says about Microsoft's opinion of the feature overall. The main purpose for UAC, the company insists, is to encourage developers to fix their applications to make them more secure. "Fix" here can mean a few things—refrain from admin-level operations altogether so that there is no need to elevate at all; split the application into several pieces so that some operations can be privileged but not others; and in extreme cases, mark the application so that it elevates as soon as it is started. With the exception of the last option, the effect is the same: the application runs most or all of the time without full Administrator privileges, and as such is easier to run as a standard user. Because the prompts are annoying—deliberately so—developers are hence encouraged to make their applications run without elevation as much as possible, so as to refrain from annoying the user.
That's all fair enough. Except it means that the prompts must be shown. If the prompt is hidden (due to automatic elevation) the annoyance no longer exists, and there's no longer any incentive for developers to avoid elevation. With silent elevation it's easy to just elevate willy-nilly; the user will never know, so there's no downside. Fortunately, third parties aren't able to automatically elevate, so they're forced to consider carefully when and where to elevate. In Windows Vista, Microsoft too had to weigh up the options, because Vista didn't have the automatic elevation mechanism.
Except that now, with Windows 7, Microsoft is saying "While that's fine for third parties, it's not actually good enough for us; we don't think our software should show users prompts, even when it's doing something that needs elevation." Microsoft's software no longer pays any penalty for elevation (it happens silently and automatically), so no longer needs to be designed to avoid it. Third-party software doing a protected operation—creating folders in protected locations, say—will show a prompt. Explorer, however, won't.
To my mind, this is ridiculous. Either these actions are dangerous and should generate prompts, or they're not and they shouldn't. For Microsoft to say that they're only dangerous when other people's programs do them makes a nonsense of the whole situation. Third-party software has to choose between avoiding the operation in question or generating a prompt. Microsoft can do the operation regardless; Redmond no longer needs to care.
If the actions that Microsoft software can perform are not so dangerous as to warrant prompts, then that same privilege should be afforded to third-party software. Admin Approval mode should automatically elevate for any software—not just Microsoft software. Either UAC should prompt all the time or it shouldn't prompt at all. The principle that a user-initiated operation is safe when performed by a Microsoft executable but unsafe otherwise just isn't coherent. The safety of an action is determined by the action itself (deleting system32 isn't safe even if I use Explorer to do it) and the broader context of the user's action; deleting a folder in Program Files is safe if I'm intending to purge remnants of a shoddy software installer, but not if I'm merely attempting to uninstall the program in the first place. The UAC prompts trapping the action regardless of intent may not be perfect, but they're a lot closer to being right than silent elevation.
Thus the Windows 7 Admin Approval changes are bad on two levels: not only do they open up significant backdoors to allow automatic silent elevation by malicious software, they also make a mockery of the entire premise behind Admin Approval mode.
Insult to injury
What really adds insult to injury is that the prompts were no bad thing. The protected filesystem locations, for example, are protected for a reason—there is little reason for people to create new files and folders within Program Files directly; such activities should be performed by installers. Microsoft had the right idea with Vista—discourage people from doing things that they probably shouldn't be doing—but with Windows 7 it has now lost its nerve. Rather than making it easier to do these dubiously useful things, the company should have stuck to its guns, and insisted on retaining the prompts, even if people hate them. Moreover, the company should have strived to make UAC into a true boundary. There's no technical reason why it couldn't be, and the computing environment would be far safer it it were. It would just take some work to achieve.
It is worth noting that running Windows 7 as a standard user, using over-the-shoulder elevation, avoids all these flaws, as it lacks automatic elevation. However, the utility of this mode in typical home scenarios is not obvious. The first (and only) user created during the Windows 7 install process is an Administrator-level user. For typical users to benefit from over-the-shoulder mode they would have to create a second account and switch to using that as their default. This may very well be the best practice, but in the real world it is unlikely to be of any value in most home user contexts. After all, if using a regular user account had been standard practice among home users there would never have been any need for UAC (and especially Admin Approval mode) in the first place.
If Admin Approval mode is really going to be this inconsistent and unfair, Microsoft should just bite the bullet and make all Admin Approval mode prompts go away, and implicitly elevate. As it is, the only people who get hurt by this are third parties, since malware and Microsoft software will be able to bypass the prompts anyway. Sure, this will mean that Admin Approval mode is no better than running Windows XP as an Administrator—but that seems to be Redmond's perverse intent anyway.
again. So that's it then. UAC in Windows 7 has been rendered completely and totally useless. This isn't a problem that can be fixed, since it's done using a well-documented API. It's still going to prompt you to install things or run 3rd party programs, but any malware can bypass it easily. So it still has most of the annoyance with none of the security. In it's default mode, it's absolutely pointless. If Microsoft refuses to change this, they might as well set the default UAC setting to "off", since that will provide that same security.
Of course, it possible legitimate 3rd party programs are going to take advantage of this exploit, and in a few years you may never even know UAC exists since nothing you do or run will trigger a prompt.
