Opinion: Windows 7’s UAC is a broken mess; mend it or end it

The changes Microsoft has made to Windows 7's UAC render it little more than a …

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.

107 Reader Comments

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.

You can thank the Slashdot crowd for that, which complained (rightfully) when running as an Admin was required for nearly every program, and then turned around and started bitching endlessly about UAC when Microsoft finally fixed it. There's actually a slashdot comment complaining that a Windows dev friend of his had to take time to separate privileged code from non-privileged code. Imagine if you complained about that in the UNIX world; you'd be laughed out of the room.

I just run Windows 7 UAC in the low mode, the last 'rung' on the little slider. This mode is the same as the "no bitch/no elevate" mode in Vista, it doesn't really do much of anything other than allow IE to run in a protected memory space...plus, it doesn't annoy the crap out of me. What can I say, I like to grab life by the balls and live dangerously.

Didn't Microsoft said they fix the problem in RC, and set that the default option of UAC is at max (Vista behavior) and that you need Admin privileges to change the UAC prompt?! So the problem is fixed. Reducing this bar, is like disabling it under Vista, with a touch of illusion (unless it's all the way at the bottom). But that is the user fault, not Microsoft. This is the problem when really large companies listen too much to their wide range consumers. Personally, I think Microsoft should have not touch UAC. People will learn to get used to it and that's final. I really think that UAC in Windows 8 will be back to Vista behavior, or have some list with options to customize it. So that you can remove it, lets say, when you edit the Start menu for all users and you are under "Admin" type account. Which was the annoying part for some when they first got Vista.

Other things that Microsoft listen too much to people, is that people were claiming that the fact that when you maximize a window and the boarders and task bar turn dark and opaque was a bug. When clearly it was not. Now Vista ready application that uses Aero (buttons on transparent area of the window, like Windows Media Player 11 and Glasser theme for Firefox), makes them unusable under Windows 7, as is you have a bright, animated, or changing background, it distracts you and keeps you thinking that Windows wants you attention., but it does not. Oh and it's ultimately useless. It's not a transparent 18-27px height of transparency on top of a window that will do anything to your life. Not large enough to see a gadget nor icon. It's just plane annoying now. I wish Microsoft revert back to Vista behavior or AT LEAST have an option to change the behavior.

Microsoft is trying to play both sides of the fence here, pretending they care about security while also pretending they care about usability. In reality they don't know anything about either one nor do they care, and are now attempting to convince people that some kind of balance can be had between these 2 things while building on top of the pile of trash that is Win32. It isn't possible, you can't bolt on security to a system that was designed by very smart people and then completely fucked sideways by the idiots who managed it for the better part of the last 2 decades at Microsoft.

UAC is the result, so have fun with that. Anyone expecting them to do something competent will be disappointed no matter what happens.

What I would have liked to see addressed here is the risk level when running Windows 7 with secure prompting for credentials is enabled for all elevations. I would think that this would provide an adequate level of security, and it's not such a pain if you use biometric security for example. While nothing is bullet proof wouldn't this get you close to a linux box with Sudo?

As nice a problem as UAC tries to solve, it really doesn't get at the heart of most things. It's designed to prevent drive-by download apps from installing themselves, not the unauthorized users from crapping on their system like OS X and UNIX.

Vista's UAC was doing precisely what it was designed to do. It was getting 3rd parties to shape up and improve their apps so that they would not depend on admin privileges when it was completely unnecessary. With these sorts of flaws in the new system, coupled with the fact that most users will be running in this UAC mode, i see far less need for 3rd parties to improve their code.

I also cannot reconcile this with any of the tenets of the security push at MS.

Wow that article had a couple good points, but also a lot of sheer burning hate! It took me a while to understand what was meant by "Do as I say" - what sort of nefarious double standard was the evil empire propagating?

quote:

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.

Dude, we're talking about Explorer here. A system component whose most common scenarios are file operations performed explicitly by the user. It's not like Media Player or Notepad are going to start adding auto-elevated components. I think you're blowing this a bit out of proportion. Plenty of Windows components still pop up prompts right and left. Your megahurtz will be OK.

quote:

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.

Uh, and both will still require elevation in Windows 7. Users shouldn't be mucking about in Program Folders unless they know what they're doing.

Personally, I'd vote for fewer elevation prompts when doing Windows activities, and the same level or more when 3rd party code is trying to do something fishy. Windows 7 seems to have suffered from the "sky is falling" reactions to Vista's UAC. Which really weren't completely unjustified. You can't just drop something like that on Joe User and expect him to intuit the design decisions and the security paradigm behind it. Hell, MS should've just bought TV ads pre-Vista and explained to people what was to come. A sort of "The More You Know...your PC". I hereby copyright this idea btw.

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)

I'm running the Win7 beta. I R-click in Program Files and select 'New Folder' from Explorer. Bingo - the UAC prompt appears. All your alarmist fantasies about MS giving its own programs special privileges is just claptrap.

Yes, I run UAC at 'Always Notify', since that's the recommendation for the beta and I'm not terminally stupid. I've installed a large numbers of programs and only a proportion of the older ones require privilege elevation in normal use. This can usually be fixed either by changing a setting in the program itself or by altering the permissions on folders specific to that program alone. Setting UAC to max has no impact on my day-to-day use of the machine.

The link you provide admits this, "Setting UAC to its highest level, or using a non-admin account, will prevent the proof-of-concept from working by forcing it to display a UAC prompt." This 'flaw' is easily defeated with a couple of clicks, something you fail to point out.

You could have simply said this is another reason why the default UAC level in the Win7 beta is too low, but then that's hardly news, has been discussed many times before by others and I guess it wouldn't make such a showy headline for your opinion piece.

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.

You can thank the Slashdot crowd for that, which complained (rightfully) when running as an Admin was required for nearly every program, and then turned around and started bitching endlessly about UAC when Microsoft finally fixed it.

Have you ever seriously considered the notion that any population of people—never mind the population of users at any website—are not homogeneous in their beliefs?

quote:

There's actually a slashdot comment complaining that a Windows dev friend of his had to take time to separate privileged code from non-privileged code. Imagine if you complained about that in the UNIX world; you'd be laughed out of the room.

The link you provide admits this, "Setting UAC to its highest level, or using a non-admin account, will prevent the proof-of-concept from working by forcing it to display a UAC prompt." This 'flaw' is easily defeated with a couple of clicks, something you fail to point out.

Approximately no-one uses non-default settings. I mean, hell, if you're going to use non-defaults, you should be using a regular user account (no Admin Approval mode at all), right?

Except by and large, people don't, because people don't change the defaults. Even in Vista, the majority of end-users stick with UAC's defaults, because they don't know any better.

My problem with UAC is not the annoying prompts (I know why they are there so I can live with it). But the crap about not being able to save files anywhere else than documents folder (I freaking hate that crap, I decide where my files go not MS), not to mention that it refuses to even prompt for saving files to the root of the drive (including USB stick) so you can't even create a directory without going to explorer.

It's that kind of completely retarded things that are ruining it. Messing with windows directory or program files should be UAC prompted but random others really don't need to be.

Originally posted by charleski:You could have simply said this is another reason why the default UAC level in the Win7 beta is too low, but then that's hardly news, has been discussed many times before by others and I guess it wouldn't make such a showy headline for your opinion piece.

I'm not impressed.

You could say the same thing about WinXP not having the firewall enabled by default - and it had a huge impact on security. The fact that Microsoft, again, ignored security tenets and didn't filter in the good and instead filtered out the bad shows that there are some lessons they still refuse to learn. MS can "wink" and proclaim it's not security and it is like saying this "glass pipe with water reservoir and filter" is not a bong. Either way, they're high if they thing anyone is buying that line.

I think the article proves, beyond doubt, its premis of a broken system. The new "setting" only stops legitimate 3rd programs from accessing areas without a prompt, not highly exploitable MS components and not malware that will use them. I, for one, actually trust UAC in Vista and this is a first trust I've ever had for an MS OS (even without it being a *security boundary*).

*sigh* Didn't we just have this same discussion a few weeks ago, Peter? You don't appear to have added anything new.

quote:

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.

This, if we stipulate that the lower default UAC setting will remain post-beta, is the only core truth. Admin Approval mode UAC is easily subverted under both Vista and Win7. The only difference is how fast and consistent the subversion can be done. With both systems, it does not stop malware. With both systems it does stop accidental use of privileges. The WriteProcesMemory/CreateRemoteThread approach is never going to be a standard way non-malicious applications elevate themselves because it is neither robust nor easier to implement than simply properly factoring the application.

quote:

Microsoft's software no longer pays any penalty for elevation...

Massively misleading statement there. Microsoft makes quite a bit of software. All of thus sound and fury is only about components that ship in the box with the operating system.

quote:

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.

No - you are arguing they make a mockery of your flawed assumption about Admin Approval mode's premise not the premise Microsoft had in mind.

quote:

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

This we have been over before. Go read and/or watch Russinovich's discussion of exactly that topic. Yes, there are a whole list of technical reasons why it can't be so. There is some possibility, after some gradual and massive changes to the whole Windows software ecosystem, that it will be possible a few versions down that line to make Isolation Levels/Restricted Tokens into a true boundary, but it is not possible today without breaking a huge percentage of applications.

Originally posted by DrPizza:Approximately no-one uses non-default settings. I mean, hell, if you're going to use non-defaults, you should be using a regular user account (no Admin Approval mode at all), right?

So, you admit that nothing has changed since this story first broke a month ago then? Then, as now, it was revealed that to enable proper UAC security in the Win7 beta you need to set UAC to max. We should continue to lobby MS to release Win7 with UAC set to max by default, but nothing has changed since the initial analysis of the new UAC settings.

There is absolutely nothing new here, even the 'vulnerability' that's supposed to be the foundation for the headline is based on a 3-week old posting. The story is mere froth that was concocted purely to provide an excuse for an inflammatory and wholly misleading headline.

This is hack journalism at its worst and I'm sad to see Ars lower itself to this level.

use of privileges. The WriteProcesMemory/CreateRemoteThread approach is never going to be a standard way non-malicious applications elevate themselves because it is neither robust nor easier to implement than simply properly factoring the application.

It is absolutely robust.

MS's software should not be privileged. MS apps should be forced to annoy users just like everyone else's.

Originally posted by geofflee:If only Microsoft can auto-elevate and 3rd parties can't, then I smell antitrust coming real soon.

Yup barrier to entry in many levers most importantly in legal terms.

I really question anyone that doesnt think everyone needs to follow the same security rules. Anything else is asking not only to fail but fail in a very visible and embarrassing way. I do like UAC when it is on someone elses computer less tech support but no one like it on their own computer unless they are an insider or use command line.

Originally posted by DrPizza:Approximately no-one uses non-default settings. I mean, hell, if you're going to use non-defaults, you should be using a regular user account (no Admin Approval mode at all), right?

So, you admit that nothing has changed since this story first broke a month ago then? Then, as now, it was revealed that to enable proper UAC security in the Win7 beta you need to set UAC to max. We should continue to lobby MS to release Win7 with UAC set to max by default, but nothing has changed since the initial analysis of the new UAC settings.

What is different is that there are more known exploits, and that they're not going to be fixed. MS's "response"--making it so that changing the UAC setting causes a prompt--misses the point totally. The new system is filled with systematic, reliably exploitable flaws (which wasn't the case in Vista), and the new system gives MS's own components an unfair advantage over third parties.

That's bad. It's bad because it's less secure. And it's bad because it shows that MS doesn't really believe any of this security stuff. Trust based on executable signatures just isn't good enough.

First: The WriteProcessMemory/CreateRemoteThread approach only works with if you are starting with an admin account, so an honest application would need a whole different code path to work for a standard user. That is not a robust development approach.

Second: It is fragile in the case of changes from Microsoft. Doing this in an normal application (rather than in malware) would be akin to using undocumented APIs, and then begging Microsoft to break you with a hotfix. Would you ship an application built that way? I certainly wouldn't.

--

I don't know if Microsoft has already considered this, but there's a fairly straightforwards way to fix this problem. Isolation Levels are not limited to the three commonly in use today. While it would need extensive regression testing, I would consider changing the loader to run white-listed applications at some new level that is between normal and elevated. This would avoid the remote thread issue (and the standard shatter attacks that also apply but I haven't heard anyone mention yet.)

First: The WriteProcessMemory/CreateRemoteThread approach only works with if you are starting with an admin account, so an honest application would need a whole different code path to work for a standard user. That is not a robust development approach.

That's good enough for most purposes; it's the default, after all.

quote:

Second: It is fragile in the case of changes from Microsoft. Doing this in an normal application (rather than in malware) would be akin to using undocumented APIs, and then begging Microsoft to break you with a hotfix. Would you ship an application built that way? I certainly wouldn't.

It is a technique that has worked for as long as the APIs have existed. Even new stuff like ASLR and DEP does nothing to stop it (though if they made system library randomization per process rather than per boot, that'd make things a little more inconvenient). But the basic WriteProcessMemory/CreateRemoteThread technique is robust. And documented and supported--what else is CreateRemoteThread for, if not creating threads in other processes? It is more consistent and reliable than a number of other documented APIs, too.

Now, could they do something to harden the new UAC against such attacks? Sure, they could do a stack walk, for example, to ensure that the IP at all points in the chain belongs to trusted libraries. That'd raise the bar considerably, I believe, but there might be significant performance implications But as of right now, they've not done anything of the sort.

quote:

I don't know if Microsoft has already considered this, but there's a fairly straightforwards way to fix this problem. Isolation Levels are not limited to the three commonly in use today. While it would need extensive regression testing, I would consider changing the loader to run white-listed applications at some new level that is between normal and elevated. This would avoid the remote thread issue (and the standard shatter attacks that also apply but I haven't heard anyone mention yet.)

Though that sounds good on its face, I'm not sure if it'd do the job; it's quite easy to get Explorer to load a third-party DLL anyway. Unless you made the necessary registry locations high integrity too, which is probably a good idea anyway. I think the real problem is that there are so many avenues for medium integrity processes to undermine higher integrity processes, MS just doesn't want to go through and fix them all, thereby ensuring that "not a boundary" remains the case.

Originally posted by DrPizza:It is a technique that has worked for as long as the APIs have existed. Even new stuff like ASLR and DEP does nothing to stop it (though if they made system library randomization per process rather than per boot, that'd make things a little more inconvenient). But the basic WriteProcessMemory/CreateRemoteThread technique is robust. And documented and supported--what else is CreateRemoteThread for, if not creating threads in other processes? It is more consistent and reliable than a number of other documented APIs, too.

You missed the key point there. Yes, CreateRemoteThread works, but it is not robust in use against an adversary that is actively trying to defeat it. If applications make a practice of using using that approach to hitch a ride on white-listed components Microsoft will certainly release hotfixes that break those applications. This is exactly like the arms-race over PatchGuard, and it will have the same effect. Malware will still try all avenues it can find, but normal software developers will choose the easier path and design their applications properly.

Applications that actually need to "silently elevate" under Vista already do so, simply by factoring out the elevated code into a service installed during setup and an unprivileged user interface that controls that service via a private API. This is what, for example, all anti-virus software already does. This will still be the easier/cheaper/better way for new applications to be written as compared to trying to create a remote thread in an moving target.

quote:

Though that sounds good on its face, I'm not sure if it'd do the job; it's quite easy to get Explorer to load a third-party DLL anyway. Unless you made the necessary registry locations high integrity too, which is probably a good idea anyway. I think the real problem is that there are so many avenues for medium integrity processes to undermine higher integrity processes, MS just doesn't want to go through and fix them all, thereby ensuring that "not a boundary" remains the case.

It certainly wouldn't be perfect, but that's been my point all along - UAC is not perfect, it cannot be perfect without breaking a huge chunk of the existing application base. Microsoft can not "go through and fix them all" because those avenues are there to support application compatibility for third party code too. Again - please go listen to Russovich on this topic. This is not "Microsoft doesn't want UAC to be secure" and continuing to repeat that refrain just costs you and Ars credibility.

Which makes it an annoying stinking mess. Either you have the rights to do something or NOT. Annoying users is an idiotic idea in every area (I look at your certificate handling firefox) Shitty hybrid modes like that should have been killed from the start. If they are not able to provide a decent user experience while running as non-admin they should either overhaul the OS or get back to admin by default mode. Not some in-between mode.

Why won't Microsoft just install an admin and a user account by default? If normal users on a normal Windows 7 system have to elevate with the admin password, 3rd party programs *really* screw themselves if they require *any* elevation past installation.

UAC is broken in Windows 7, I've been using it and following its development. If MS wants 3rd party developers to write applications so they don't write files on the Program folder, or the root or some other protected area, but then malware can do all that, doesn't that ring some alarms? And if you can use Explorer to move the whole Program folder somewhere, without prompts? If that's going to be the case, then bring Vista back.

I've developed applications, many years ago, that now had to be made Vista compatible. I know the effort it takes, so they write data where they're supposed to, and then creating an installer that is compatible as well. If you do everything by the book, it takes some effort. But if you can go around this and keep your applications mostly unchanged by using a simple trick, you're going to see a lot of them behave that way.

At some point MS will have to break compatibility and free the system from having to live with past bad decissions. This is a step that MS will have to take sooner or later. Run old programs in a VM, and give us a better OS, please.

You missed the key point there. Yes, CreateRemoteThread works, but it is not robust in use against an adversary that is actively trying to defeat it. If applications make a practice of using using that approach to hitch a ride on white-listed components Microsoft will certainly release hotfixes that break those applications.

Do you think? I am not the least bit convinced, simply because creating remote threads (unlike patching the system service table or other kernel data structures) is a supported, legitimate operation.

quote:

This is exactly like the arms-race over PatchGuard, and it will have the same effect. Malware will still try all avenues it can find, but normal software developers will choose the easier path and design their applications properly.

Why? Microsoft hasn't. Microsoft has said, "Oh, this is too hard, we'll just slap a signature on our applications and just continue blindly on our way". Why shouldn't third parties demand the same?

quote:

It certainly wouldn't be perfect, but that's been my point all along - UAC is not perfect, it cannot be perfect without breaking a huge chunk of the existing application base.

I don't think that's true.

I think the biggest victim would be Windows itself; most third-party code runs as a regular user well enough. The most problematic software, by far, is Windows.

quote:

Microsoft can not "go through and fix them all" because those avenues are there to support application compatibility for third party code too.

Come now. We were told with XP SP2 and again with Vista that from now on, tradeoffs between security and compatibility would tend towards security. If doing UAC properly means breaking some applications--and I'm not at all convinced that it will, in general--then those applications should be broken. If someone really needs to run a program that won't work with the new security? Let them use MED-V (which ought to be built-in, not some Software Assurance extra, but that's another issue--the point is, MS has a solution to the problem that works and which doesn't compromise the OS).

And the Win7 UAC design isn't being done for compatibility anyway. It's being done to allow users to retain bad practices. Security has totally lost out here.

quote:

Again - please go listen to Russovich on this topic. This is not "Microsoft doesn't want UAC to be secure" and continuing to repeat that refrain just costs you and Ars credibility.

I don't follow. MS said with Vista that they wouldn't use signatures because it wasn't secure (even if not a true boundary, they still wanted the thing as secure as they could muster). Now they are using signatures anyway, without doing anything to mitigate the problems of a signature-based scheme. Clearly security has lost out here.

Originally posted by DrPizza:Do you think? I am not the least bit convinced, simply because creating remote threads (unlike patching the system service table or other kernel data structures) is a supported, legitimate operation.

Really? Please point me at where Microsoft has ever hinted that creating remote threads inside explorer, or any other app, is a supported operation? The API is supported for use between your own applications. Using it on a third-party application has never been supported - if it works, good, if not, don't ask for help from Microsoft.

quote:

Why? <em>Microsoft hasn't</em>. Microsoft has said, "Oh, this is too hard, we'll just slap a signature on our applications and just continue blindly on our way". Why shouldn't third parties demand the same?

You are continuing to intentionally confuse "Microsoft's applications", with components of the operating system. The two are not the same thing.

quote:

I don't think that's true.

I think the biggest victim would be Windows itself; most third-party code runs as a regular user well enough. The most problematic software, by far, is Windows.

You thinking it doesn't make it so. Once again, go listen to Russovich.

quote:

Come now. We were told with XP SP2 and again with Vista that from now on, tradeoffs between security and compatibility would tend towards security. If doing UAC properly means breaking some applications--and I'm not at all convinced that it will, in general--then those applications should be broken.

Again, only for your, mistaken, definition of "properly". You can't seem to get through your head that you are the only confused about that.

quote:

If someone really needs to run a program that won't work with the new security? Let them use MED-V (which ought to be built-in, not some Software Assurance extra, but that's another issue--the point is, MS has a solution to the problem that works <em>and which doesn't compromise the OS</em&gt.

Building it in, as it currently stands, is rather pointless as it requires a big infrastructure. Yes, however, a virtualization based solution to app compat is certainly the right choice in the future.

quote:

MS said with Vista that they wouldn't use signatures because it wasn't secure (even if not a true boundary, they still wanted the thing as secure as they could muster). Now they are using signatures anyway, without doing anything to mitigate the problems of a signature-based scheme. Clearly security has lost out here.

I have no clue what you are trying to imply here. Microsoft has always supported using signatures for making security decisions. That's the basis for locking things down with group policy, signed scripts, powershell, active-x, etc.

Really? Please point me at where Microsoft has ever hinted that creating remote threads inside explorer, or any other app, is a supported operation? The API is supported for use between your own applications. Using it on a third-party application has never been supported - if it works, good, if not, don't ask for help from Microsoft.

Where is that constraint specified? The documentation says that it's a useful API for e.g. injecting a break into another application when writing a debugger. One might very well want to debug Explorer (e.g. to debug a shell extension), and certainly any debugger worth a damn will be break into Explorer (Visual Studio can, of course). I'm sorry, but this "own applications" constraint is not and never has been a part of the contract of CreateRemoteThread. It is something of your own concoction. The fact is, creating remote threads is robust, documented, and supported.

quote:

You are continuing to intentionally confuse "Microsoft's applications", with components of the operating system. The two are not the same thing.

There is no meaningful distinction between an "OS component" like Media Player and an "application" doing the same thing. If one should be privileged, so should the other.

quote:

You thinking it doesn't make it so. Once again, go listen to Russovich.

Good grief, it's as if you think I haven't heard what he has to say on the matter. I have; it's just not relevant. The fact is, most UAC prompts come from Windows itself. That's why Win7's autoelevation is regarded as such a big "win"--because of the huge reduction in prompts it causes. It's not third-party software causing loads of prompting; it's Windows.

quote:

Again, only for your, mistaken, definition of "properly". You can't seem to get through your head that you are the only confused about that.

MS is claiming it to be a security feature. MS is claiming that (in Vista) decisions were made because of their security implications. That's not coming from me. That's coming from Microsoft. You can talk about Russinovich 'til you're blue in the face--he does not trump the claims made elsewhere.

quote:

Building it in, as it currently stands, is rather pointless as it requires a big infrastructure. Yes, however, a virtualization based solution to app compat is certainly the right choice in the future.

It's been the right choice since at least the Vista era (XP was too soon, given the hardware that was extant, but the ubiquity of multicore large memory systems in the Vista era makes virtualization the proper solution), it just hasn't been the choice they've taken.

quote:

I have no clue what you are trying to imply here. Microsoft has always supported using signatures for making security decisions. That's the basis for locking things down with group policy, signed scripts, powershell, active-x, etc.

Microsoft explicitly stated that Vista's UAC would not use signature-based exemptions because signatures are not a secure mechanism for creating such exemptions. They said that using signatures for such a purpose would undermine the security of UAC.

And yet that is precisely what Windows 7 is doing, with precisely the result that MS expected.

I don't understand how Microsoft's solution to convincing 3rd parties to clean their code i.e. annoying end-users, is so acceptable around here.

That is assuming that is the only purpose of UAC, as a lot of folks here are claiming.

Also, the problem with UAC does not lie in the conception, but in implementation. When I have UAC prompts pop up asking me if I want to do what I JUST told the OS to do (non-privileged operations, like creating a folder) then that is just silly and annoying. MS needed to find a different way to distinguish automated operations from user-generated operations.

Riemann Zeta:I just run Windows 7 UAC in the low mode, the last 'rung' on the little slider. This mode is the same as the "no bitch/no elevate" mode in Vista, it doesn't really do much of anything other than allow IE to run in a protected memory space...

If MS are going down the current path then that's what I think should be the default. Either have prompts or don't have them since as soon as you let one unelevated process opt out of prompts you let all of them do so, except the ones that play by the rules.

As well as running IE in "low integrity" mode, you do still get the benefit of code only running elevated when it needs to. That means attacks which modify behaviour (e.g. overwriting the name fo the file to delete in memory) still have barriers against modifying system files. (Obviously a full code-injection vuln that can launch processes is not protected against, but that is the case with the Win7 defaults right now and that's why the prompts with the defaults are just security theater.) It also means that bugs in unelevated code are less likely to cause damage. (e.g. Code that accidentally attempts a recursive delete on a system folder will fail. I've seen those bugs before.)

quote:

GoodBytes:Didn't Microsoft said they fix the problem in RC, and set that the default option of UAC is at max (Vista behavior) and that you need Admin privileges to change the UAC prompt?! So the problem is fixed.

Microsoft said nothing of the sort. The only things they said they would change are the UAC control panel (now triggers a UAC prompt) and, possibly, the gaping hole in RunDll32.exe (exactly how or what they will change there is unknown and they aren't sharing any information or later betas with the public).

Microsoft have not said they will change the default UAC level. They also have not even asked me for details on the proof-of-concept code, let alone the code itself, despite several people (myself included) contacting them about it. They seem to be ignoring the issue but keeping the security-theater default prompt level.

quote:

GoodBytes:Other things that Microsoft listen too much to people, is that people were claiming that the fact that when you maximize a window and the boarders and task bar turn dark and opaque was a bug.

I think you've misunderstood the issue there. It was about multiple monitors. If you maximize a window on one monitor, all the glass on other monitors (where things may not be maximized) goes opaque as well. It looks kinda ugly, IMO. Windows 7 now leaves glass translucent all the time. (So I read; I've only run it on a VM which doesn't support Aero.) A better solution may have been to only make glass opaque on monitors with maximized windows.

quote:

Vlad:Dude, we're talking about Explorer here. A system component whose most common scenarios are file operations performed explicitly by the user. It's not like Media Player or Notepad are going to start adding auto-elevated components.

We're not just talking about Explorer here. As my video shows, you can elevate through Calc.exe, Notepad.exe, MSPaint.exe...

Also, what about replacements for Explorer and Task Manager? There are far superiour programs in both categories. If it's a good idea for users to be able to manage admin files/processes/etc. without prompts then it should not matter which tool they use to do it. And Microsoft have proven that they are not special when it comes to safeguarding their processes from exploitation, so what possible argument is there for not allowing other processes to have silent elevation? (And what's the point anyway when allowing any process to silently elevate means all others can piggyback on it?)

quote:

Vlad:[b]Uh, and both will still require elevation in Windows 7. Users shouldn't be mucking about in Program Folders unless they know what they're doing.

Silent elevation. Under default settings in Windows 7 users do not see UAC prompts when mucking about in Program Files. MS have not said they will change those settings so we can only assume it'll be the same in the RTM.

quote:

[b]charleski:I'm running the Win7 beta. I R-click in Program Files and select 'New Folder' from Explorer. Bingo - the UAC prompt appears.

Yeah, because you increased the UAC level from the default. Nobody is arguing that Windows 7 cannot be as secure as Vista. We're arguing that it isn't by default and the way it has been changed is illogical and security theater at the cost of annoying third-party app users while no longer providing a security benefit.

quote:

charleski:We should continue to lobby MS to release Win7 with UAC set to max by default, but nothing has changed since the initial analysis of the new UAC settings.

What has changed is that it's been shown that the flaws in Win7's UAC are not limited to a few easy-to-patch things like the UAC control panel or RunDll32.exe. They are systemic.

quote:

charleski:There is absolutely nothing new here, even the 'vulnerability' that's supposed to be the foundation for the headline is based on a 3-week old posting

A three-week old posting that has had very little attention paid to it so far. AFAIK only The Register have run an article about it and that did not discuss it in depth (it was mostly just a link to one of the videos). I've been talking to Peter over the last few weeks and I know he wanted to write about this sooner but he was trying to do the right thing by researching the issue, and whether Microsoft were doing anything about it, before publishing.

So it's not a brand-new, zero-day issue but it's news to most people. It also should shut-up the people saying "stop complaining about UAC as Microsoft have said they will fix it," because MS haven't said they will fix this. They haven't even asked me for the details of it, despite me (and several others) contacting them.

quote:

AxMi-24:My problem with UAC is not the annoying prompts (I know why they are there so I can live with it). But the crap about not being able to save files anywhere else than documents folder (I freaking hate that crap, I decide where my files go not MS), not to mention that it refuses to even prompt for saving files to the root of the drive (including USB stick) so you can't even create a directory without going to explorer.

Sounds like the permissions are not set correctly on the folders you want to copy into. I have data folders all over my machine, including at the root level of some secondary harddrives, and I can copy into them without UAC prompts on Vista.

quote:

BlakeCoverett:The WriteProcesMemory/CreateRemoteThread approach is never going to be a standard way non-malicious applications elevate themselves because it is neither robust nor easier to implement than simply properly factoring the application.

It is very robust now and will remain so unless Microsoft add protections against it. Microsoft have not even asked me for the details so they seem not to care about protecting against it. So you can't really argue that "it won't be a problem if it's fixed" when MS are showing no desire to fix it. Half the argument is that we are trying to convince them to fix it. (The other half is that if they won't fix it then they should scrap the prompts as they are pointless and unfair on third-party system apps.)

You're right that non-malicious code should not depend on this method for elevation because it's against the rules and could be broken in a Windows update. (Unless, I guess, it offers it as a "silent elevation" option tht the user has to switch on and can turn off if it breaks.)

The point is, malicious code doesn't give a damn about robustness or working with every future version of Windows. So here we have a system that malicious code can easily exploit, but which punishes non-malicious code by forcing it to display UAC prompts (or write a service, which I'll get to in a minute).

What's the point of that, exactly? If only non-malicious code triggers UAC prompts, and malicious code can work around them, then I question the benefit of them.

quote:

No - you are arguing they make a mockery of your flawed assumption about Admin Approval mode's premise not the premise Microsoft had in mind.

What is the premise of UAC, then? It seems to change whenever its convenient. It's difficult to argue for or against a moving target. That's why I've been arguing that either it should be improved or the prompts should be turned off by default, depending on what the actual aim of it is.

If the aim of UAC is to force developers to refactor code to compartmentalise admin tasks then that can be achieved without displaying elevation prompts for all apps. (And if it's important to minimize the frequency of elevation, and thus make the prompts annoying, then doesn't that apply to Microsoft's own software as well? Why do they get a free pass for a system they designed themselves?)

quote:

This we have been over before. Go read and/or watch Russinovich's discussion of exactly that topic. Yes, there are a whole list of technical reasons why it can't be so.

"It cannot be perfect" isn't an excuse for making it worse.

Either UAC prompts do something important or they don't. If they are important then they should be made as difficult as possible to bypass, rather than just displaying them in a few places to give the illusion of security while anything that wants to can bypass them. If they are not important then they should be turned off by default. It's pretty simple.

quote:

Doing this in an normal application (rather than in malware) would be akin to using undocumented APIs, and then begging Microsoft to break you with a hotfix.

FWIW, there's nothing undocumented involved in bypassing UAC to copy a file. The thread/code injection APIs are documented, the elevation API is documented and the IFileOperation COM object is documented. What happens after that, to exploit the copied file into allowing arbitrary elevated execution, is using an undocumented hack. (It's actually a fourth problem in Windows 7's UAC which I've not discussed publically as it does't seem important. I'd happily tell MS about it if they wanted to fix it but, like I say, they don't seem to care.)

The undocumented part was just the first thing I could think of that woudl allow arbitrary elevated execution. There's probably a documented way you could do the same thing if someone wanted to think about it but I never saw of thinking about it further as I just wanted to demonstrate that the proof-of-concept code could do more than simply "copy a file." I literally only spent a few minutes looking for the first thing I could exploit to prove the point.

quote:

You missed the key point there. Yes, CreateRemoteThread works, but it is not robust in use against an adversary that is actively trying to defeat it.

You are missing the key point that Microsoft have shown zero interest in trying to defeat it. Your argument seems to be that this isn't an issue because it could be fixed. Of course it could be fixed, else nobody would be saying "it should be fixed!"

quote:

Applications that actually need to "silently elevate" under Vista already do so, simply by factoring out the elevated code into a service installed during setup and an unprivileged user interface that controls that service via a private API.

So why didn't Microsoft do that with their own apps? Why do they get a shortcut while everyone else has to write services?

And do we really want the Serivces list cluttered with even more crap than it already contains?

And do we trust everyone to write services in a way which is secure and cannot be controlled by other software?

If silent elevation is a good idea then the OS should provide it as an option, user configurable, for all programs so that developers don't have to reinvent it and do a half-arsed job in the process.

quote:

Microsoft can not "go through and fix them all" because those avenues are there to support application compatibility for third party code too.

That is probably true. They may not be able to fix everything. But it doesn't give them the excuse to completely break everything, either, and then on top of that still claim that with default settings the UAC prompts -- which only get in the way of legitimate apps now -- are neccessary.

Let me see if I have this straight, you first bitch that UAC is to annoying. Then you bitch it is to permissive? It may have flaws but it's still going in the right direction. Unless you can come up with a better way?

The bigger issue here is that MS, under Ballmer, continues to flounder with the companies flagship product. Vista's sales numbers are due, almost entirely, to the MS lock on the new PC market. Meanwhile Apple and Linux are gaining market share. MS cannot afford for Windows 7 to be seen as Vista, the sequel. Vista was not a compelling upgrade from XP. In a tight economy no company is going to pay a premium for another flawed MS offering.