Symantec shows Microsoft how to do UAC

Symantec shows Microsoft how to do UAC

Summary: Security company Symantec has released a tool that helps to make Vista's UAC (User Account Control) feature clearer and less of a pain to use.

SHARE:
TOPICS: CXO, Microsoft
45

Security company Symantec has released a tool that helps to make Vista's UAC (User Account Control) feature clearer and less of a pain to use.

Norton UAC Tool in action!

Norton UAC Tool (which, I will warn you right from the start is currently in beta) is a replacement to the UAC prompts that you normally see. It has two usability-related features to offer:

It offers a "Don't ask me again" feature so that the next time you carry out a certain action there's no UAC prompt displayed

It gives you more information about what's triggered a UAC prompt. Specifically:

  • Whether the app is digitally signed (and if so, who it is signed by)
  • Whether the component resides in a protected directory

Symantec shows Microsoft how to do UAC  Symantec shows Microsoft how to do UAC

Symantec shows Microsoft how to do UAC  Symantec shows Microsoft how to do UAC 

Symantec shows Microsoft how to do UAC  Symantec shows Microsoft how to do UAC

Symantec shows Microsoft how to do UAC  Symantec shows Microsoft how to do UAC

Symantec shows Microsoft how to do UAC

Before installing this tool, read the Norton UAC Tool FAQ carefully, especially the following points:

Q: What does Norton Labs get out of my testing? A: DATA! Each time you see a prompt, the Norton Labs UAC Replacement sends meta information about what caused the prompt, and why, to our server. This data will be used, in aggregate, to help Norton Labs build a white list that can be shipped with the UAC replacement and LiveUpdated as needed.

Q: What do you mean by "meta information"? A: The meta information contains file name and file hashes for the EXE that caused the prompt and the EXE that is to be the recipient of the elevated privileges. In addition, the meta information contains file name and file hashes for DLLs that were active in either of the two EXEs, response information (what option did the user choose, how quickly, and did they choose "do not ask me again"), and date/time info.

Also be aware that since this is a beta product, it might introduce vulnerabilities to your system. With that in mind I'd keep this tool off critical systems (or systems connected to critical systems).

Still, it shows that the UAC mechanism can be improved upon, and that a few small tweaks can make the mechanism much more user-friendly.

Thoughts?

Topics: CXO, Microsoft

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

45 comments
Log in or register to join the discussion
  • So I don't have to wait for Windows 7?

    The need to wait or upgrade to Windows 7 is looking more dim for Windows Vista users. Microsoft just yesterday announced their intention to improve the user experience for UAC in Windows 7. But with third party company's such as Symantec aiming to fix UAC now, a lot of what Microsoft is promising as an upgrade is looking less interesting. I am sure 7 will present new improvements, but do I really need to invest in a brand new version of Windows to get all of them? I don't think so too.
    Mr. Dee
    • But if you don't want a Symantec product

      or don't want to pay for it (or another 3rd party company's
      offering) to handle/enhance an existing OS feature, then I
      hope M$ continues to make this feature more user friendly.
      At least Symantec just gave M$ a clue about usability
      enhancements it could make. And why not make that in Vista
      and Windows 7?
      Spats30
  • thats freekin cool

    Again what Symantec did..MS should have done from day 1 - would have made UAC acception/adoption much more plesant. Who would have thought to put a 'dont ask me again' check box? Amazing!

    Look for MS to buy this shortly...
    JT82
    • Except...

      Except it is a dumb idea. Read some of the posts below to see why this is a severe security hole all in itself. If you still don't understand why this is a bad idea, then you don't understand Security 101.

      Biggest surprise is that Symantec thought it was a good idea. I guess a sale is more important that actually keeping people safe.
      Qbt
  • The problem with "don't ask me again"...

    The problem with "don't ask me again" is that the system has to know that *you* specifically are the one taking the action requesting the prompt. I'm curious if these Symantec prompts make any attempt to determine this, otherwise it's a giant elevation of privelege hole.

    Let's say there's an unpatched code execution vulnerability in my web browser and I go to a site that tries to exploit it. My browser runs at low integrity (IE) or regular/medium integrity (Firefox), and so I know that any exploit can't do anything administrative without my permission because a UAC prompt would need to appear first.

    However, what if they try to launch something that I'd already said "don't ask me again" for? Is Symantec smart enough to know that the request didn't really come from me? It's really, really hard to determine the difference between the exploit case and a legitimate case.

    Yes, they could do something like compare which process originated the requests, but now substitute a web browser vulnerability with a vulnerability in Explorer.exe (e.g. ones where viewing certain malicious video files in thumbnail view allows remote code execution). Explorer is the main launch point for apps in Windows so this scenario could be quite dangerous.
    PB_z
    • Re: The problem with "don't ask me again"...

      That's the first problem with "don't ask me again". The second problem is how do you stop the installers of apps applying this setting as part of their install, to avoid the need for fixing their code to run as non-admin.

      Aaron Margosis had a post I like on this topic: http://blogs.msdn.com/aaron_margosis/archive/2007/06/29/faq-why-can-t-i-bypass-the-uac-prompt.aspx

      [i]
      "If it were possible to mark an application to run with silently-elevated privileges, what would become of all those apps out there with LUA bugs? Answer: they'd all be marked to silently elevate. How would future software for Windows be written? Answer: To silently elevate. Nobody would actually fix their apps, and end-user applications will continue to require and run with full administrative permissions unnecessarily.

      What if the application could not mark itself for silent elevation but instead had to be marked by the consumer or enterprise administrator installing the application? Answer: the developer of the installation program (which necessarily runs with admin/system permissions in order to install machine-wide) would figure out where the setting lived, and set it. (Several major ISVs told us directly that they would in fact do exactly that.)"
      [/i]
      davewood [MS]
      • Then why does Windows itself require so many prompts?

        If the aim of UAC in Windows Vista is to implore on third party developers to improve their security privileges in their applications, then why does Windows Vista require so many unnecessary UAC prompts in locations of the OS such as changing Date and Time? I have never heard of a malicious program for instance invoking me to do a backup. UAC does not have clear understanding of the lucrative areas of the OS that malicious programs like to attack.

        UAC still does not protect the areas of the OS that should be protected the most. For instance, a friend of mine running Vista Home Premium '64-Bit' had UAC disabled through an attack and also disabled all Administrative Privileges: Command Prompt, MSCONFIG, Task Manager and Shutdown options were all killed. Why wasn't UAC instrumental in protecting all these critical areas of the system? Not even traditional areas like System Properties could be accessed or certain Control Panel items. So there is indeed some work that needs to be done, it needs to be effective that users are seeing results. I personally want an option to check off areas of the system I deem to be safe so I don't see the prompt anymore. Of course, I do consider myself to be a power user. I personally have not encountered any malicious attacks on my system running Vista since RTM, but I have seen friends who have and they never disabled UAC. What I had to do to save that system from a format was to boot into Safe Mode and run System Restore to an earlier point before the attack had occurred.
        Mr. Dee
        • Re: Then why does Windows itself require so many prompts?

          Windows, like most OSes, has a permission-based model, where the core areas of the system are prevented from being writable by processes that do not have adminstrator privileges. UAC aims to permit processes to do these operations only with explicit approval from the user. Currently Windows processes don't get special-cased: anything that needs to change system settings will normally bring up a prompt.

          In a similar way, UAC doesn't try to distinguish "safe" modification of system settings from "unsafe" ones. This just isn't feasible - the UAC system can't guess about the thousands of settings in Windows. If the creator of the setting decided it required Administrator privs and set the permissions that way then UAC must respect those permissions.

          But in your particular example, I can think of many security-related concerns with allowing non-admin processes to change the date and time. A machine may have an anti-virus scan that runs at a specific time so malicious code might modify the time to prevent the latest virus signature files from being downloaded and the malicious code detected. Or if security updates are checked and downloaded on a schedule the malicious code might try to interfere with that.

          As for your friend's attack, I don't know how UAC was bypassed - is it possible he or she inadvertantly downloaded and executed some code and allowed it to elevate? Regardless, somehow code managed to 'punch-through' the barrier between non-admin and admin code. Once malicious code is running with administrator rights on the machine, then it can do anything. No part of the system can be protected at this point, because administrator code can do, well, anything. The goal must be to stop malicious code gaining admin privs in the first place.
          davewood [MS]
          • Whats the point of 'Standard' Administrator account then?

            I thought the point of the new Standard Administrator account and UAC was to prevent easy attacks like the one I described. She was running with the out of the box Standard Administrator account setup by Windows Vista. Anything less (like Limited User Account) and I am sure she wouldn't want to use her computer. You made some valid points about the Date and Time issue. But then again, what about the other areas of the system I mentioned and protection she expected, she had an updated AV, Firewall on and her system was still infiltrated.

            I thought the point of UAC was to protect users from themselves. As for her computer habits, surf the web, email, IM, social networks and of course download music. Even if malicious code was downloaded, how did it manage to run? The fact that she is even running Vista '64-Bit' which includes more sophisticated protections like Patch Guard, ASLR, Device Driver signing, I would have at least hope that one of them would be there watching out for her. The only things that rescued her were Safe Mode and System Restore.
            Mr. Dee
          • Not sure how many times you've got to be told this but...

            ...malware cannot disable UAC without the UAC dialog appearing to elevate privileges. If malware really did disable UAC she had to have authorized it to do so.
            ye
          • Even then

            it would require a system reboot to complete disabling of UAC I thought? Not hard to notice! Something like UAC suddenly not prompting isn't a subtle change.
            SamCPP
          • Protecting users

            Nothing can protect users, but training. Even that is not much use if users ignore it.

            With UAC, antivirus, IPS, etc, the whole goal is to protect the computer and the network, not the user. Some products like UAC, runas, and SUDO are put in place to allow users to assist in that protection. They get to use more security, and maintain the ability to be productive when security gets in the way.

            Even, in the Military they will tell you Mission comes first then security. IT managers job is to make sure work gets done as securely as possible, but it's a job were we know that assets must be put at risk for the business to go and to grow.
            tomam
        • I call BS (again).

          [i]For instance, a friend of mine running Vista Home Premium '64-Bit' had UAC disabled through an attack and also disabled all Administrative Privileges: Command Prompt, MSCONFIG, Task Manager and Shutdown options were all killed.[/i]

          No he didn't unless he permitted the malware to do so.
          ye
        • Good question.

          "why does Windows Vista require so many unnecessary UAC prompts in locations of the OS such as changing Date and Time?"

          UAC is partially about giving system administrators more control, so it's not just about security. This is annoying to the consumer, but more understandable to the business.

          Some businesses may have software where knowing the correct time is critical to its function, and this can prevent accidental (or malicious) setting of the date and time.

          In addition, some programmers don't do a good job with the date/time stuff, so when the date and time are set to something unexpected, it may cause some programs to crash.

          "For instance, a friend of mine running Vista Home Premium '64-Bit' had UAC disabled through an attack"

          That's pretty much game over. UAC is a vital security mechanism, and disabling it is disabling a vital part of Vista's security model.

          "Why wasn't UAC instrumental in protecting all these critical areas of the system?"

          You just said it was disabled. It can't work if it's disabled.

          "I personally want an option to check off areas of the system I deem to be safe so I don't see the prompt anymore."

          Then use this software from Symantec. And keep in mind Microsoft designed the OS, so they know why they decided to protect certain parts of the OS.

          "I personally have not encountered any malicious attacks on my system running Vista since RTM, but I have seen friends who have and they never disabled UAC."

          Keep in mind that ultimately UAC only limits the damage: Anything in user mode can still be affected by malicious software.

          Theoretically, this *should* mean that you can just reset the user profile, although I personally would reformat and restore a backup.
          CobraA1
      • Yes that is a point but

        maybe the OS should cater for that. Is it impossible for an OS to store and secure data from users?
        SamCPP
      • Re: The problem with "don't ask me again"...

        The Norton UAC tool allows an application to run with silently-elevated privileges only in a specific context that was previously approved by the user with the "don't ask again" check box selected.

        This means that there is a difference between regedit.exe launched from the start->run box, regedit.exe originating from a shortcut double click, and regedit.exe launched from a double click on a .reg file (and the context actually changes with each .reg file), and regedit.exe being launched by an application (malicious or not).

        Given the contextual awareness of Norton UAC tool's automatic answering, this is a clear usability improvement over Vista's default UAC prompts, while maintaining obvious security improvements in the Vista kernel (such as isolation, file/registry virtualization, and user interface privilege isolation) that are all disabled when UAC is disabled.

        In the current release, we do allow the user to choose to "remember" their selection for consent prompts for any application/context, however we may restrict this in the future.
        scooley [symc]
    • re: The problem with "don't ask me again"...

      "However, what if they try to launch something that I'd already said 'don't ask me again' for?"

      a) They'd have to find a way to exploit the code in the application they wish to launch as well as your browser.

      b) They'd have to figure out you had already given permission for that application.

      c) Depending on how Symantec implemented this, launching the application may be all they can do. Just asking the OS to launch something doesn't imply you have access to it or control over it.

      d) You can actually already do something like this with the Task Scheduler. You can create icons that don't prompt for UAC (after going through an initial UAC prompt to create a task that requires admin approval). So it's already theoretically possible.

      "Is Symantec smart enough to know that the request didn't really come from me?"

      Possibly. UAC already has some functionality built in to distinguish between keystrokes/mouse clicks that come directly from the drivers and simulated keystrokes/mouse clicks that come from user mode applications.

      You [b]are[/b] relying somewhat under the assumption that they put a lot of thought into the implementation and didn't just put in some sort of quick hack.
      CobraA1
      • That is the problem

        There is absolutely no way for either the OS or other security software to know that the elevated operation was initiated from the user or from some malicious software. Unless they analyze the code paths that were executed after the user clicks or types, there just is no way to do it reliably. There is a *lot* of code that is executed from the time when I click something until the operation is completed.

        So let me say that again: Unless the OS or security software analyzes the actual code paths (and is able to verify that it is indeed a legit user-initiated operation), the "don't ask me again" approach is a severe security hole.

        Imagine I click on a link in the browser to download and run an executable. I know the executable is legit. So I choose "don't ask me again". The next day, I browse to some shady website, the site uses a browser vulnerability to initiate an download and run operation, but because I said previously that I should not be asked again, it goes ahead and downloads and executes the file. Owned. Especially since I was the one that originally went to the site in the 1st place (and hence initiated the operation). The security software logic will need to analyze the code that was executed to really know that this time around the elevated operation was caused by something else.

        Anybody that thinks "don't ask me again" is a good idea does not understand the original problem.

        I am really surprised that Symantec actually thought this was a good idea. It shows they are more interested in making a sale than actually keeping people safe.
        Qbt
        • No need to analyze code paths, there are other ways.

          "There is absolutely no way for either the OS or other security software to know that the elevated operation was initiated from the user or from some malicious software."

          Processes don't exchange data directly in a modern OS. The OS is heavily involved nearly every step of the way, and it's keenly aware of the status of all of the information going around.

          "Imagine I click on a link in the browser to download and run an executable."

          The drivers send the clicks with the OS, the OS sends the clicks to the shell, the shell asks the OS to load the application, the OS loads the application into memory, the OS checks to see if it needs escalation, etc. The OS is involved nearly every step of the way - it could be as easy as adding a few bits to the data that only the OS is allowed to touch that identifies the source of the data.

          "but because I said previously that I should not be asked again, it goes ahead and downloads and executes the file."

          The program that gets launched determines if it wants admin approval, not the program doing the launching. The program requesting the launch has no control over UAC. It asks the OS to launch the other program, and the OS looks at the program being launched and decides whether the program launched needs UAC.
          CobraA1
          • You don't understand the problem

            The idea behind UAC is to alert the user that an application is attempting to perform an operation that requires elevated privileges. The OS has no idea what the application logic is doing, so it relies on the user to confirm that the operation was really initiated by the user.

            Let me use another example:

            Let's say you use Photoshop. You save your images to a file location that requires elevated privileges to access. So the first time you try to save the image, the OS puts up the AUC prompt to tell the user that Photoshop is requesting to perform an operation that requires elevated privileges. Since this happened right after the user attempted to save the file, the user is sure that this is a valid operation and the OS should grant Photoshop the right to do this.

            But then the user goes ahead and checks the brain-dead "don't ask me again" checkbox.

            The next day, hackers discover a vulnerability in Photoshop, which can be exploited by loading a malicious image (we have seen this many times before). So the user finds one of these images, and loads it up into Photoshop. The image causes a stack overflow bug to be triggered, and code embedded in the image gets executed. Next, the malicious code attempts to save a virus onto the system. Since the malicious code is running in the context of Photshop, which the user happily told the OS to give free reign of the whole system, the malicious code is now free to do whatever it likes, without popping any UAC prompts.

            So the only way to get around this problem is to analyze the code paths and determine if the elevated operation the app is trying to perform really came from a user request, or from some other way. Really, there is no way to make this secure, other than asking the user every time whether they approve the specific elevated operation or not.

            If you can't see that "don't ask me again" is a dumb idea, then again, you don't understand Security 101.

            Basically, if you grant an app "don't ask me again" rights, you better hope that there is never again a vulnerability discovered in that app that can allow arbitrary code execution, because if there is, there is nothing stopping your system from being owned. I wonder who we will blame when that happens?
            Qbt