yes or no: User Account Control

[Mordkanin]

I'm not sure if you're a programmer, but from your comments I will assume not...

Processes may be able to ask explorer to launch an app for them (I'm not an expert on the Win32 API as I use the .NET Framework), but the way programs ask Windows to do anything is through programming interfaces. The way explorer works internally is not seen or known by the calling program. As a result, I'm sure the programming interfaces called by explorer when you ask it to open a program are different from those called by other programs. MS can also throw a UAC prompt when an external application calls one of those interfaces when explorer is running in evelated priv. (and I'm sure they do now)...

So basically... It isn't impossible to know how an application is lauched. If it were MS wouldn't have been able to ensure UAC prompts came up in the first place ;)

No. I'm aware of how you can launch apps, and how Windows knows how they've been created. I'm talking about actually getting explorer to do it for you. Explorer doesn't run as a 'high' level process, so process isolation won't stop other normal processes from mucking around with it.

I'm not fully aware of how it all works with hooking into explorer to make it do stuff for you, I've never really looked into all that kind of weird stuff (It's on my list of things to learn, though,). But surely you've seen apps do some weird stuff with explorer. But even with my relatively limitted knowledge, i'm pretty sure you can register a shell extention and have it do something (It would then be seen by Vista as running as explorer, right?), or hell, even just mimic win+r, "cmd /k myapp", enter.

Or better yet, launch a copy of explorer hidden, and then play with its window. I'm not 100% sure if that'd work, but it's possible.

Edited August 12, 2007 by MioTheGreat

[apollo_1444]

i disabled the minute i installed vista.

[Brandon Live Veteran]

I'm not sure you caught all that I was saying. It could have been bad wording on my part so I hope I don't fail in that regard again...

I don't think it would be an increased security risk adding an "Allow this app" for the reasons I previously stated. In the example you gave, if an app/process started that wanted to run CMD.exe which was previously grated rights to always run in admin then there should be a UAC prompt. This UAC prompt would then tell the user that this app/process is attempting to call CMD which is an admin level app/process. That way an app/process isn't allowed to elevate itself through a back door. To my knowledge Vista already works this way with process isolation when UAC is on. UAC would also automatically turn off the "Allow this app" if the application exe ever changes to prevent malicious code from patching the exe to gain the priviledges.

That doesn't make any sense at all. What you're describing is the current behavior - if something tries to launch a process in an elevated context, you receive a UAC prompt. The user (and the system) have no idea who really made the request to launch the application. As others have said, all I have to do is inject code into Explorer (or any other process) and it looks like the request is coming from there (because it is). It's trivial to inject code into another process of the same privilege level.

Unelevated apps can write to %ProgramFiles%... I've installed apps that did not need a UAC prompt to write to Program Files... Expresso (www.ultrapico.com/Expresso.htm) was one of them.

They absolutely cannot, unless you've changed the default ACLs on that directory (a ridiculously horrible idea). If an unelevated application attempts to write to %ProgramFiles%, it will be redirected to the per-user virtual store. That is, unless the application is UAC-aware and has requested not to be redirected. In that case, it just gets a standard E_ACCESS_DENIED error.

I'm glad we both agree it needs improvement. I think it falls horribly short as a protection mechinism though. As we all know the key to real security is informed users. When UAC reaches that point of informing users properly it will become that; the single best security feature on Windows. Today it is just a bright idea.

I don't agree. While there is room for improvement (particularly around the UI, Secure Desktop implementation, etc) - it's already the best individual security feature on Windows.

[Leo Natan]

While there is room for improvement (particularly around the UI, Secure Desktop implementation, etc) - it's already the best individual security feature on Windows.

:laugh:

[Brandon Live Veteran]

:laugh:

Is that the face of ignorance?

[Leo Natan]

No, it's the face of laughing when hearing a good joke.

[gigapixels Veteran]

But what Brandon said is no joke. While most of what you see from UAC are those "annoying" pop-ups for authorization, there's much more behind the scenes that has enhanced Windows security far more than anything else, including even anti-virus and anti-spyware software.

[Brandon Live Veteran]

No, it's the face of laughing when hearing a good joke.

Good thing you're here to make such worthwhile contributions to the discussion.

Could you at least point to the security feature that you think does more for today's Windows users?

[MrCobra]

If you're talking about something like Sandboxie,

Sandboxie is ok but I was thinking more along the line of things like DropMyRights. IE in uber low privelage mode can not be exploited easily and cannot write to system folders or execute most code(s).

[ozgeek]

Good thing you're here to make such worthwhile contributions to the discussion.

Could you at least point to the security feature that you think does more for today's Windows users?

Yes there is one - it's called User Awareness of what he's up to. If she/he surfs porn then he deserve what happens to his computer (unless he takes messure to protect his computer, but if average joe basically checks emails from family and friends, knowingi not to open unknown emails, and surf like a light surfer, then UAC is way over the top. Too much security for too little purpse. A computer is supposed to be used happily, not drive users craky with repetitive requests. Think the computer of your Office Assistant, would you like it if the OA asks you if you are sure of this or that everytime you order her/him to do anything? I really though MS was concerned with user experience and ease of use...if that is the case then decrease the number of mouse clicking. I guess they lost the knowledge of RSI (http://en.wikipedia.org/wiki/Repetitive_strain_injury).

[kouhii00]

Yes there is one - it's called User Awareness of what he's up to. If she/he surfs porn then he deserve what happens to his computer (unless he takes messure to protect his computer, but if average joe basically checks emails from family and friends, knowingi not to open unknown emails, and surf like a light surfer, then UAC is way over the top. Too much security for too little purpse. A computer is supposed to be used happily, not drive users craky with repetitive requests. Think the computer of your Office Assistant, would you like it if the OA asks you if you are sure of this or that everytime you order her/him to do anything? I really though MS was concerned with user experience and ease of use...if that is the case then decrease the number of mouse clicking. I guess they lost the knowledge of RSI (http://en.wikipedia.org/wiki/Repetitive_strain_injury).

Your average joe statement contradicts itself. But anyways can you give me a scenario where I can make UAC prompt me? Exclude the scanarios where I will have to modify something in my C:\, C:\windows\, C:\program files, "start menu", or C:\system32. From my experience if something is gonna be changed within those folders I wanna know wtf it is but besides that I wouldn't care.

[jbo]

Yes there is one - it's called User Awareness of what he's up to. If she/he surfs porn then he deserve what happens to his computer (unless he takes messure to protect his computer, but if average joe basically checks emails from family and friends, knowingi not to open unknown emails, and surf like a light surfer, then UAC is way over the top. Too much security for too little purpse. A computer is supposed to be used happily, not drive users craky with repetitive requests. Think the computer of your Office Assistant, would you like it if the OA asks you if you are sure of this or that everytime you order her/him to do anything? I really though MS was concerned with user experience and ease of use...if that is the case then decrease the number of mouse clicking. I guess they lost the knowledge of RSI (http://en.wikipedia.org/wiki/Repetitive_strain_injury).

Good point, let's get rid of porn and fill the internets with happy sites of cats! CAN'T WAIT!

P.S. PM me when you're done!

[TheNay]

I agree with Brandon, it is the best individual security feature on Windows ever, however, I think it's only good for non-power users.

People who are well aware of the surfing habits and etc should be able to avoid the naggin pop ups if they know what they're doing.

I have UAC disabled, never liked it, but if I get infected one day b/c I have it disabled my problem and I'll take the blame.. lol

However, I haven't gotten a virus, rootkit or spyware program installed by accident for years so we'll see, maybe i'll turn it on if something new and tricky is out there that's unstoppable ;) All in all, UAC is a gr8 security safety shield.

[Jeff-Flowers]

Personally, I leave UAC on. I am hardly ever bothered and after running XP as a limited user for a year, I find it to be easy to do. And for those who just need to run one or two programs that require elevated rights, I would look at this hint:

http://sbs.seandaniel.com/2007/05/how-to-l...s-elevated.html

[raskren]

Wrong. I love Vista. It has made my computing life much more pleasenting than XP as long as UAC is off. Running Vista with UAC is no difference than running XP. As long as you don't visit bad sites or do anything that cause the OS to be exploited then it is good without UAC. Windows Updates is there for a reason.

So basically you're saying that turning off UAC opens a gaping security hole?

Unless you are psychic, there's no way to tell what 0 day exploit is around the corner. The ANI exploit is a prime example. A few "trusted" websites hosted the drive by exploit which blows away the "don't visit bad sites" "security layer."

[+LogicalApex MVC]

No. I'm aware of how you can launch apps, and how Windows knows how they've been created. I'm talking about actually getting explorer to do it for you. Explorer doesn't run as a 'high' level process, so process isolation won't stop other normal processes from mucking around with it.

I'm not fully aware of how it all works with hooking into explorer to make it do stuff for you, I've never really looked into all that kind of weird stuff (It's on my list of things to learn, though,). But surely you've seen apps do some weird stuff with explorer. But even with my relatively limitted knowledge, i'm pretty sure you can register a shell extention and have it do something (It would then be seen by Vista as running as explorer, right?), or hell, even just mimic win+r, "cmd /k myapp", enter.

Or better yet, launch a copy of explorer hidden, and then play with its window. I'm not 100% sure if that'd work, but it's possible.

I recommend you do look into how it works as I really don't have the time to give you a crash course in Object Orientated Programming?(OOP) and the Windows 32 Application Programming Interface?(Win32?API) or the .NET Framework Common Language Runtime. (.NET/CLR)

A simple way of understanding it is an important OOP component is object seperation. An object is never supposed to know, or care about, what another object is doing internally. It simply accesses that object through its public methods and properties. This allows the programmer to change the way things work internally without breaking things that depend on an object.

Windows is programmed in an OOP fashion. A process can interact with the operating system in a zillion ways, but all using public interfaces MS defined. If an application does process injection type attacks to change the way anything works INTERNALLY to that Windows component then that program is acting maliciously. Situations like that?is?why?CPU?makers?added?the?NX?(No?Execute)?bit?to?modern?CPUs?and?MS?added?DEP?(Data?Execution?Protection)?to?Wind

ws.

To make a long story short... If an app could access any process or component of Vista INTERNALLY (meaning not through the public methods and properties MS has defined in the API) then there is already a fundamental security breach in Windows. UAC would be rendered useless then as there would be nothing preventing a process injecting the UAC code and making it think you clicked continue. That is why Process Isolation was developed...

So since MS knows every way a program can talk to any part of the OS the feature I recommended wouldn't be a problem... If the "Allow this app" feature was so insane MS wouldn't have added that option to IE7 with Protected Mode since IE is the one area where most Windows Exploits arrive.

That doesn't make any sense at all. What you're describing is the current behavior - if something tries to launch a process in an elevated context, you receive a UAC prompt. The user (and the really o idea who really made the request to launch the application. As others have said, all I have to do is inject code into Explorer (or any other process) and it looks like the request is coming from there (because it is). It's trivial to inject code into another process of the same privilege level.

No I'm describing current behavior with some changes. Read my comment above as Windows DOES know what is starting applications and the injection argument is silly at best.

And as I stated before, the user is given so little information that it really doesn't matter if they are required to hit "Continue" everytime they start the app or not. If your argument of code injections is accurate an exploit could compromise the system by attempting to start an innocent action that requires UAC and after the user hits continue inject code into that innocent action's process and do whatever it wanted.

Of course, that shouldn't be possible with Process Isolation so adding a "Allow" option wouldn't be a problem.

They absolutely cannot, unless you've changed the default ACLs on that directory (a ridiculously horrible idea). If an unelevated application attempts to write to %ProgramFiles%, it will be redirected to the per-user virtual store. That is, unless the application is UAC-aware and has requested not to be redirected. In that case, it just gets a standard E_ACCESS_DENIED error.

You are correct, sorry for my mis-information in this regard. The UAC prompt for that app came late in the insta:| so I forgot seeing it :| I guess I'm already getting conditioned to just hitting "Continue" or "Allow" all the time...

I don't agree. While there is room for improvement (particularly around the UI, Secure Desktop implementation, etc) - it's already the best individual security feature on Windows.

I won't keep running in circles here; we disagree and will continue to.

[Brandon Live Veteran]

Ack, double-post, read below.

[Brandon Live Veteran]

If an application does process injection type attacks to change the way anything works INTERNALLY to that Windows component then that program is acting maliciously. Situations like that is why CPU makers added the NX (No Execute) bit to modern CPUs and MS added DEP (Data Execution Protection) to Wind

ws.

To make a long story short... If an app could access any process or component of Vista INTERNALLY (meaning not through the public methods and properties MS has defined in the API) then there is already a fundamental security breach in Windows.

I realize you're probably not a Windows programmer, but basically everything you described is completely false. It's very easy (and common) to inject code into different process. Heck, my Start++ app does it. There are literally dozens of ways to do it, but probably the most common is using SetWindowsHookEx(). You provide it a DLL and an entrypoint and it will load it into the WindowProc of any thread/window you specify (or all of them, if you choose) running on the same desktop.

Can it be used for evil as well as good? Sure. But that's A) Assuming that code is already on your box, and B) Something that UAC and UIPI were designed to help with.

What you described is the perfect way to circumvent UAC/UIPI. Fortunately, you aren't designing Windows :)

UAC would be rendered useless then as there would be nothing preventing a process injecting the UAC code and making it think you clicked continue. That is why Process Isolation was developed...

UAC prompts are protected in multiple ways. First, they are running in an elevated context, so they are protected by UIPI. They are also displayed on a different desktop and protected in numerous other ways.

So since MS knows every way a program can talk to any part of the OS the feature I recommended wouldn't be a problem... If the "Allow this app" feature was so insane MS wouldn't have added that option to IE7 with Protected Mode since IE is the one area where most Windows Exploits arrive.

That's quite a different scenario. IE is one self-contained application, and all code running inside of it is locked down to only interacting with other Low IL objects. Therefore IE can always be sure that any requests to launch an application are coming from inside itself. And since the "ieuser.exe" and "iexplore.exe" are owned and written by the same people, they can ensure that calls to "elevate" out of protected mode are only coming from non-injectable code surfaces.

You really can't do that at the OS level, because if you did create an API like ShellExecute() where an application can say "Hey Windows, launch this program. And by the way, it's really me and this code wasn't injected" - do you really think the injected code isn't going to lie and say "You can trust me, I'm definitely not injected code!"

But let's ignore that and pretend you came up with a foolproof way for an application to tell you that a call is coming from inside its "original" code (which is pretty much impossible - ever wonder why UAC doesn't bother telling you *who* tried to start the application?). Now you still have to convince application developers to start using this API and meeting its requirements (code signing, etc), explain to users why sometimes they can say "remember this" and sometimes they can't, and assume that developers using this never mess up and accidentally expose the entire system to attack.

Pretty much, it's not a feature you're likely to see. At least not the way you described it.

No I'm describing current behavior with some changes. Read my comment above as Windows DOES know what is starting applications and the injection argument is silly at best.

It's pretty clear you don't know enough about Win32 programming to say things like that, so perhaps you shouldn't.

And as I stated before, the user is given so little information that it really doesn't matter if they are required to hit "Continue" everytime they start the app or not. If your argument of code injections is accurate an exploit could compromise the system by attempting to start an innocent action that requires UAC and after the user hits continue inject code into that innocent action's process and do whatever it wanted.

That's what UAC, UIPI, and other measures are designed to protect against. That's why a malicious app can't get you to elevate Notepad and then inject itself there. The elevated app is protected by a secureable object marked as High Integrity which prevents the unelevated app from setting window hooks, sending certain window messages, initiating drag-and-drop, calling OpenProcess(), etc.

Of course, that shouldn't be possible with Process Isolation so adding a "Allow" option wouldn't be a problem.

That's a non-sequitor. Process Isolation really has nothing to do with whether or not there should be an "Allow" option.

Off the top of my head, the greatest concerns with an "Allow" option are:

1) Is the code you're trying to run identical to the code you "blessed." This is perhaps the easiest to solve.

2) Is it being launched with the same:

Command-line parameters

Working directory

STARTUPINFO struct

3) Is standard input/output being redirected? Do you trust the redirection?

4) Has data the application is going to access been manipulated?

5) Is the application installed in a trusted location? Is it signed? What about any libraries it loads at runtime?

6) What about the caller? Is he installed in a trusted location? Identical to when the call was "blessed"? Signed?

And I'm not even a security guy...

Edited August 13, 2007 by Brandon Live

[ZonoBurk]

Yes there is one - it's called User Awareness of what he's up to. If she/he surfs porn then he deserve what happens to his computer (unless he takes messure to protect his computer, but if average joe basically checks emails from family and friends, knowingi not to open unknown emails, and surf like a light surfer, then UAC is way over the top. Too much security for too little purpse. A computer is supposed to be used happily, not drive users craky with repetitive requests. Think the computer of your Office Assistant, would you like it if the OA asks you if you are sure of this or that everytime you order her/him to do anything? I really though MS was concerned with user experience and ease of use...if that is the case then decrease the number of mouse clicking. I guess they lost the knowledge of RSI (http://en.wikipedia.org/wiki/Repetitive_strain_injury).

There could never be too much security.

[+LogicalApex MVC]

I realize you're probably not a Windows programmer, but basically everything you described is completely false. It's very easy (and common) to inject code into different process. Heck, my Start++ app does it. There are literally dozens of ways to do it, but probably the most common is using SetWindowsHookEx(). You provide it a DLL and an entrypoint and it will load it into the WindowProc of any thread/window you specify (or all of them, if you choose) running on the same desktop.

Can it be used for evil as well as good? Sure. But that's A) Assuming that code is already on your box, and B) Something that UAC and UIPI were designed to help with.

What you described is the perfect way to circumvent UAC/UIPI. Fortunately, you aren't designing Windows :)

I'm not sure if you are just arguing for the sake of arguing or if you actually have valid points to make... The comments you make are as if you read nothing I've said throughout this entire thread...

SetWindowHookEx() like other function calls are PUBLIC INTERFACES... That means MS dictates what happens when you're code calls that interface and asks it to do something. If that is not the case then why are you calling any interface in the Win32 API to inject this code?

I'm not really sure what you're trying to say...

UAC prompts are protected in multiple ways. First, they are running in an elevated context, so they are protected by UIPI. They are also displayed on a different desktop and protected in numerous other ways.

So now you're saying there IS ways Windows stops applications from using interfaces like you said to inject themselves... Humm... Still not sure what you're saying

That's quite a different scenario. IE is one self-contained application, and all code running inside of it is locked down to only interacting with other Low IL objects. Therefore IE can always be sure that any requests to launch an application are coming from inside itself. And since the "ieuser.exe" and "iexplore.exe" are owned and written by the same people, they can ensure that calls to "elevate" out of protected mode are only coming from non-injectable code surfaces.

You really can't do that at the OS level, because if you did create an API like ShellExecute() where an application can say "Hey Windows, launch this program. And by the way, it's really me and this code wasn't injected" - do you really think the injected code isn't going to lie and say "You can trust me, I'm definitely not injected code!"

Now you're arguing that IE always knows who'se initiating something? There are countless applications that use IE internally to reder and do various things. IE knows as much about anything as Windows does. It can do it for the simple fact it is OOP designed... All those applications interact with IE on PUBLIC interfaces. Same with Windows...

But let's ignore that and pretend you came up with a foolproof way for an application to tell you that a call is coming from inside its "original" code (which is pretty much impossible - ever wonder why UAC doesn't bother telling you *who* tried to start the application?). Now you still have to convince application developers to start using this API and meeting its requirements (code signing, etc), explain to users why sometimes they can say "remember this" and sometimes they can't, and assume that developers using this never mess up and accidentally expose the entire system to attack.

I never claimed to come up with a fool proof way to do anything. I'm sure even MS will not tell you that UAC is some fool proof setup. That simply doesn't exist in security as those who circumvent seurity measures have the advantage of being able to see the security measure while those who design security measures do not get to see attacks before hand.

I only offered my opinion on areas where UAC can be improved...

Pretty much, it's not a feature you're likely to see. At least not the way you described it.

Neither one of us is in a position to say how UAC will or will not change in the future... Maybe MS will add the option, maybe they won't, time will tell.

It's pretty clear you don't know enough about Win32 programming to say things like that, so perhaps you shouldn't.

I guess you're right... I wasn't aware that every app on Windows had low level access to the hardware to do whatever it wanted at all times. I wonder why we have Windows at all when every program is doing what it wants and managing itself all the time.... Ah right that reality you're painting doesn't exist.

That's what UAC, UIPI, and other measures are designed to protect against. That's why a malicious app can't get you to elevate Notepad and then inject itself there. The elevated app is protected by a secureable object marked as High Integrity which prevents the unelevated app from setting window hooks, sending certain window messages, initiating drag-and-drop, calling OpenProcess(), etc.

So now you're again saying MS put in measures to ensure applications can't do the things you keep stating are doable? I really can't make heads or tails of what you're saying...

That's a non-sequitor. Process Isolation really has nothing to do with whether or not there should be an "Allow" option.

Off the top of my head, the greatest concerns with an "Allow" option are:

1) Is the code you're trying to run identical to the code you "blessed." This is perhaps the easiest to solve.

2) Is it being launched with the same:

Command-line parameters

Working directory

STARTUPINFO struct

3) Is standard input/output being redirected? Do you trust the redirection?

4) Has data the application is going to access been manipulated?

5) Is the application installed in a trusted location? Is it signed? What about any libraries it loads at runtime?

6) What about the caller? Is he installed in a trusted location? Identical to when the call was "blessed"? Signed?

And I'm not even a security guy...

1. I offered a potential solution to this one quite a few posts back with MD5/SHA1 hashes, but they could also keep up what they are currently doing and have the code signed. If the code is signed then any changes voids the security stamp on it. That is the point of code signing afterall isn't it?

2-6. As?I?said before,?it?would?make?sense?for?MS?to?still?throw?up?a?UAC?prompt?when?an?app?that?isn't?UAC?authorized?tries?to?open?another?app?that?is?UAC?allowed.

If Kaspersky can successfully do it in their internet security applications on Windows XP/Vista there is no argument that MS cannot...

Half of those things will also fail under UAC...

Does UAC ensure that the data has not been manipulated that program is trying to load? etc...

Once the user hits "continue" the application has full reign to do whatever it wants...

The hope is that the applications will be written so that UAC prompts are so rare that it would make the user go "that is odd", but as I stated earlier, without more information that really doesn't help the user...

But I really feel you're arguing for the sake of arguing or that you are one of the select few who believe "MS can do no wrong"...

[Brandon Live Veteran]

I'm not sure if you are just arguing for the sake of arguing or if you actually have valid points to make... The comments you make are as if you read nothing I've said throughout this entire thread...

I'm not arguing, I'm telling you how things are.

SetWindowHookEx() like other function calls are PUBLIC INTERFACES... That means MS dictates what happens when you're code calls that interface and asks it to do something. If that is not the case then why are you calling any interface in the Win32 API to inject this code?

It's a public API that gives you access to another applicaton's code at runtime... Once you have your code running in the other process, Windows has no idea what you are doing versus what the application's original code is doing.

So now you're saying there IS ways Windows stops applications from using interfaces like you said to inject themselves... Humm... Still not sure what you're saying

Yes, across the elevation boundary. But we were talking about unelevated applications injecting code into other non-elevated applications (such as Explorer.exe).

Now you're arguing that IE always knows who'se initiating something? There are countless applications that use IE internally to reder and do various things. IE knows as much about anything as Windows does. It can do it for the simple fact it is OOP designed... All those applications interact with IE on PUBLIC interfaces. Same with Windows...

When IE is used by another application, Protected Mode does not apply. "ieuser.exe" and "iexplore.exe" communicate over private interfaces, since they're both internal IE components. That's why ieuser can trust the calls it gets from iexplore.

I never claimed to come up with a fool proof way to do anything. I'm sure even MS will not tell you that UAC is some fool proof setup.

Obviously.

Neither one of us is in a position to say how UAC will or will not change in the future... Maybe MS will add the option, maybe they won't, time will tell.

Well, I certainly have to disagree there.

I guess you're right... I wasn't aware that every app on Windows had low level access to the hardware to do whatever it wanted at all times. I wonder why we have Windows at all when every program is doing what it wants and managing itself all the time.... Ah right that reality you're painting doesn't exist.

I don't even know what this means. It has nothing to do with the text you quoted above it.

So now you're again saying MS put in measures to ensure applications can't do the things you keep stating are doable? I really can't make heads or tails of what you're saying...

Again, across an elevation boundary. Perhaps you should do some reading of the UAC whitepaper on MSDN.

2-6. As I said before, it would make sense for MS to still throw up a UAC prompt when an app that isn't UAC authorized tries to open another app that is UAC allowed.

Huh? UAC prompts are never shown when an elevated application launches another process. Everything started by an elevated process is also elevated, by design (and necessity).

Thus this entire discussion is about allowing non-elevated applications to launch elevated ones without prompting the user. Doing so is clearly quite perilous.

But I really feel you're arguing for the sake of arguing or that you are one of the select few who believe "MS can do no wrong"...

I never said we can do no wrong. I was just correcting the errors in your previous posts, for the educational benefit of you and others reading the thread.

[Joel]

Bah.. UAC is crap anyway. Another feeble attempt at "security" from Microsoft.

Right, like su in *nix and stuff. Just feeble. :rolleyes:

[adcmarti]

No way. It drove me nuts :woot:

[Shasoosh]

I want to note the most annoying thing about uac

I've just downloaded FearCombat (a free fps game) , after clicking the 1.8 gigs exe file, it takes almost 3-4 minutes to identify it... Consent.exe loads and loads...

After two minutes or so (on a E6750 with 2 gigs of ram) I'm getting the "an unidentified program wants access to your computer..."

happened to me with a bunch of other softwares (the long load time)

Maybe its a problem on my end, but I don?t think so.

When uac disabled it will install instantly.

[OutblastoR]

UAC is simply lame..