Can UAC settings be made permanent?

Discussion in 'Windows Vista Security' started by Pirate Pete, Oct 24, 2006.

  1. Pirate Pete

    Pirate Pete Guest

    I participate in the Stanford University "protein folding" distributed
    computing project. I need to run a command line program called
    FAH502-Console.exe. I put it in a directory in Program Files, put a shortcut
    on the desktop and marked the shortcut "Run as Administrator." When I click
    on the shortcut icon, I still get two warnings every time I run the program:
    an unknown publisher warning (no valid digital signiture) and a UAC "unknown
    program" warning. On the first warninig, I always uncheck the "ask every
    time" box and click on Run. On the UAC warning, I click on continue (or
    whatever). The program then runs fine. But can't I PERMANENTLY approve this
    program?

    BTW, same thing when I navigate to the executable and run it by clicking on
    "Run as Administrator."
     
    Pirate Pete, Oct 24, 2006
    #1
    1. Advertisements

  2. Pirate Pete

    Jimmy Brush Guest

    Hello,

    Unfortunately, there is no way to allow a specific program to always run
    with administrator privileges every time it starts without prompting you for
    permission. This is to prevent malware from abusing this setting.

    For example, imagine the case where you have told the command prompt to
    always open with administrator privileges without prompting. In this
    scenario, a malware that does not have admin privileges could open a command
    prompt and have that command prompt perform administrator functions, since
    the command prompt would automatically receive admin privileges.

    As for the other prompt talking about a program that has been downloaded
    from the internet, you should be able to dismiss this prompt permanently. I
    believe if you perform the following steps you can get it from comming up:

    - Click start
    - Find command prompt
    - right-click it, click run as administrator
    - browse to the EXE file you need to run
    - Type its name and press enter (to start it)
    - When you are prompted, click the check box saying never to warn me again
    - Exit the program

    From this point on, I do not believe that you will get prompted for the
    unknown publisher - but like I explained, you will always get prompted for
    the administrator permission.

    Unfortunately, the program itself will need to be re-designed so that it
    will run without needing administrator permissions.
     
    Jimmy Brush, Oct 24, 2006
    #2
    1. Advertisements

  3. Pirate Pete

    Pirate Pete Guest

     
    Pirate Pete, Oct 24, 2006
    #3
  4. Pirate Pete

    Roof Fiddler Guest

    That would only be the case if Vista's shell were unable to distinguish a
    request by a user process to a open command prompt from a request by the
    console (i.e. the keyboard and mouse, whose buttons only the user has the
    ability to press) to open a command prompt. But Vista's shell can make that
    distinction, can't it? Or is the shell (mis)designed to allow ordinary user
    processes to hijack the keyboard and mouse event system, so that such
    processes can fool Vista into thinking that the user is pressing buttons on
    the keyboard and mouse when in fact he's not?

    Assuming Vista can make the distinction, then (for example) an administrator
    could configure an icon on his start menu such that, if and only if the icon
    is pressed by the user using the keyboard and/or mouse, will open a command
    prompt in administrator mode without asking for confirmation.

    The same solution would apply to the "run as administrator" option, and
    anywhere else the security shield appears, and for any program set to run as
    administrator; if the user, while logged in as administrator, moves the
    mouse and presses its buttons (or does the equivalent with the keyboard)
    such as to cause the cursor to move over the Start orb, then cause a
    left-mouse-button-click event, and then move the cursor over the icon of a
    program in the start menu which is set to run as administrator, and then
    cause another left-mouse-button-click event, then the program will be run as
    administrator with no confirmation necessary.

    Is there any particular reason why it's not done this way?

    Of course, a similar restriction would be placed on setting the "run as
    administrator" attribute for a program; only the user using the keyboard and
    mouse, or a process already running with administrative privileges, would be
    allowed to do it.

    The main point is that once a user has logged in at the console as an
    administrator, Vista can trust all local keyboard and mouse events until the
    user locks the console or logs out, and the shell, which processes keyboard
    and mouse events, can't be fooled into thinking that it's receiving such
    events when it really isn't.

    I've written previously in this newsgroup on this topic (message subject
    "Simple way to reduce UAC prompts without reducing security", on September
    05, 2006), but never got any response.
     
    Roof Fiddler, Oct 27, 2006
    #4
  5. Pirate Pete

    Jimmy Brush Guest

    Hello,

    You bring up a good point.

    The question you are getting at here is basically "Can windows tell when a
    user is running a program vs. when a program runs a program." The answer is
    no. There's a few reasons why this is the case:

    1) The UI event pipeline is not fully trusted. Although there has been some
    major work done in Vista to harden this area, I don't believe that it is
    fully trustable yet.

    2) Even if all UI input was guaranteed to come from the user through a
    trusted driver and sent to applications without modifications, Windows has
    no way of knowing what action that UI event will take, and in what context
    it was submitted (i.e. how the program asked for the input). This
    information is critically necessary in determining whether or not to throw a
    UAC prompt.

    And, I should point out here that the decision on whether to throw a UAC
    prompt or not needs to be made by the core UAC component that runs as a
    service or in the windows security subsystem, not the Windows shell which
    runs as an application in the context of the user, precisely because of that
    distinction - the Windows shell runs inside of a UAC-protected environment
    and must not have the power to override the behavior of UAC prompting. If it
    did, other applications would be able to do the same thing (even if MS made
    it extermely difficult ... it would still be possible).

    In other words, Windows cannot allow the shell to do stuff that other
    applications cannot, because from the point of view of Windows, there is no
    difference between the shell and any other third-party application, so there
    is no secure way of allowing this special behavior.

    Assuming a fully trusted UI event pipleine, an obvious solution would be to
    not display a UAC prompt if the following cirumstances are true:

    a) The user has told Windows not to prompt for a specific application
    b) A program executes that specific program while processing UI input

    Since the UI input chain is trusted in this ficticious scenario, Window is
    99.9% certain that the user has initiated the action.

    But, this solution is far from perfect, because this will bypass UAC
    prompting for approved applications while the application is processing ANY
    UI input - i.e. any keypress or any click in an application - and regardless
    of how the program requested this input.

    This would still leave the user vulnerable, because an application could
    throw up a fake window or something (for instance, a fake message box saying
    "an unspecified error has occured"), and when the user clicks the OK or
    CANCEL button the malware would then be able to launch an
    always-run-as-admin program without throwing a UAC prompt. And this is but
    one example - I'm sure the malware authors would get much more creative and
    sneaky.

    So, even though Windows knows the user initated some action, it has no idea
    WHAT action the user is trying to accomplish (because the application
    controls this, not Windows), so Windows cannot determine with any degree of
    certainty whether it is safe to allow a UAC override.

    If this functionality were implemented as you have suggested, it would
    indeed throw up some barriers that would make it difficult to create a
    malware that would take advantage of the situation - but it would not make
    it impossible. If Microsoft went ahead and implemented this, malware authors
    would catch on soon enough and adapt - making it pretty much pointless in
    implementing.

    This is a very challenging problem that presents no obvious solution, and
    will probably require a fundamental change in the way Windows is architected
    in order to solve.
     
    Jimmy Brush, Oct 28, 2006
    #5
  6. Pirate Pete

    Roof Fiddler Guest

    [snip]
    That's the root of the problem. There _should_ be a difference between the
    shell and third-party applications, in the same way that there's a
    difference between UAC and third party applications.
    Vista guarantees that when UAC takes control of the console and displays a
    confirmation dialog, it's impossible for a user-context process to press the
    "Continue" button. Similarly, the correct way for Vista to be designed would
    be for the shell to run in a separate context from the regular user context
    in the same way that UAC does, and guarantee that it's impossible for a
    user-context process to press the Start orb or perform any other such
    interaction with the shell.
    The UAC code is trusted, and it already contains GUI code (it can interact
    with the user via dialog boxes). So why not go the rest of the way, and run
    the entire shell in the UAC context?
     
    Roof Fiddler, Oct 29, 2006
    #6
  7. Pirate Pete

    Jimmy Brush Guest

    Well, a technical answer is that UAC shows its secure message boxes on the
    secure desktop. It is not possible to mix one desktop with another (this
    would kind of defeat the purpose), so you would either be able to see the
    shell OR normal applications, not both at the same time. Even if that
    problem were solved, there is still the problem with the applications that
    interact with the shell (for instance, those zip programs that plug in to
    the shell, thumbnail renderers, preview pane plugins, etc ... not to mention
    such things as the open/save as dialog boxes, which are part of the shell
    but actually run inside of another program) - are those going to be trusted
    in the same way as the shell? If not, how are they going to work?

    To answer your question at a more abstract level, I believe that UAC is
    fundamentally a policy - a set of rules that is enforced by the core
    operating system. This makes it correct for it to be implemented inside the
    heart of Windows, where it has access to everything.

    The shell, OTOH, is fundamentally an application and a platform - it is a
    bundle of core functionality/UI that is to be extended by other applications
    to make it useful. This means the shell needs to work together with
    third-party apps in order for it to function.

    If the shell was running in a more privileged environment than third-party
    apps, a problem would arise: how are the third-party apps going to interface
    with the shell? Having a privileged shell would make this extremely
    complicated, and open up the shell to privilege escalation attacks -
    applications could try to trick the shell into doing a privileged action
    that they are not able to perform themselves. No matter what security
    restrictions you put in place, this will ALWAYS be a problem with the shell
    in this scenario, because the shell MUST have a way to communicate with
    third-party apps, and with this communication line, no matter how it is
    implemented, there is risk.

    Because of this, I believe it is correct for the shell as it is currently
    designed to be unprivileged.

    And, even if you did find some way to make the shell "special" and be able
    to over-ride UAC settings without incuring a signifigant amount of security
    risk, you still haven't found a way to deal with third-party programs: How
    can Windows tell the difference between a user clicking say a button that
    says "open the command prompt" (where the user obviously is expecting to run
    a program) and the user clicking say "click here to win $100" (where the
    user DOES NOT expect a program, such as the command prompt, to run).
     
    Jimmy Brush, Oct 29, 2006
    #7
  8. To answer your question at a more abstract level, I believe that UAC is
    This is a little confusing. The operating system is NT, while the
    personality is Windows. All the GUI interfaces are Windows. At one time
    there was an OS/2 personality. A Unix personality exists, but I am not sure
    for how much longer. I believe that UAC is mostly a Windows artifact, not a
    one of the NT kernel which is the real core. Being a device driver type, I
    consider this to be extremely important though useless trivia for most
    users.

    Recent pet peeve about the Windows GUI junk: MFC allows a program to have a
    modal dialog box that resizes. However, it does not offer a way to
    automatically tag the various members of that window to be relocated and/or
    resized when it is resized. I adapted the logic in WTL in a program I
    needed to get it working, but something so obvious should be a part of MFC.
     
    David J. Craig, Oct 29, 2006
    #8
  9. Pirate Pete

    Jimmy Brush Guest

    This is a little confusing. The operating system is NT, while the
    Well, you can't run Windows without the Windows subsystem ... so I don't
    really differentiate here :)

    UAC essentially is a very simple change to the core architecture of Windows
    .... instead of a user having one security access token, there are two
    (elevated and non-elevated). I imagine this could be implemented in either
    the Windows Subsystem or the executive.

    You do bring up a good point, though ... if UAC is implemented in the
    windows subsystem, and you have another subsystem installed, would it be
    possible to bypass UAC by using the other subsystem? If so, this could be an
    issue for corporate customers who use Windows Services for Unix.
     
    Jimmy Brush, Oct 29, 2006
    #9
  10. Pirate Pete

    Jimmy Brush Guest

    I will add here that I am talking about the case where the user is logged in
    as an administrator or a user with more than "standard" privileges - this is
    the case where they have two access tokens.
     
    Jimmy Brush, Oct 29, 2006
    #10
  11. Pirate Pete

    Roof Fiddler Guest

    The desktops are already mixed (or rather, overlain). When UAC shows a
    dialog box on the secure desktop, the regular desktop is still shown. True,
    it's dimmed, and Windows refuses to allow user interaction with the regular
    desktop while the dialog box is still present on the secure desktop, but it
    doesn't have to be this way. After all, Windows used to have other annoying
    modal dialog boxes, and people complained, and as a result some such boxes
    were made to be no longer modal. There's no reason why the dialog box on the
    secure desktop has to be modal; Windows knows full well which areas of the
    screen and currently showing data from the regular desktop, and which areas
    are showing the dialog box on the secure desktop, and if I've got a Windows
    Explorer window on the left side of my screen, and I attempt a file
    operation in it which results in a UAC prompt, there's no reason for Windows
    to refuse to let me make use of the calculator on the right side of my
    screen until I respond to the UAC prompt.
    Allowing user-level programs to do these things, and other things like add
    stuff to the start menu, modify the Windows Explorer right-click context
    menu, etc without the user's explicit permission is a bug, not a feature.
    Why is it different from allowing a user-level program unrestricted direct
    access to the disk? Either way, the programs are mucking with the computer,
    and ought to have to ask permission before doing so (not that granting
    permission to plug into the shell should necessitate granting permission to
    have unrestricted disk access, but that's another issue). And it's up to the
    user in either case to decide (based on reputation of the programs' authors,
    etc) whether to trust the programs and grant permission.
    A program (or library) can be run as (or in) an administrator or user level
    process, and can even be run as (or in) multiple processes simultaneously.
    The fact that the shell program is running as an administrator-level process
    doesn't mean that some of the libraries or functions which are part of that
    program, such as open/save dialog boxes, can't also be run simultaneously
    and separately as part of user-level processes. And the presence of a
    communication channel between two processes, even if those processes are
    using some libraries in common, doesn't require the vulnerability of either
    process to being modified or hijacked by the other process.
    Perhaps in the same way that Hotmail's web servers interface with my web
    browser?
    A user-level process doesn't have the privilege to open a
    (administrator-level) command prompt, no matter which dialog boxes it
    presents to the user, and no matter what those dialog boxes say, and no
    matter where in those boxes the user clicks. If the process attempts to open
    an administrator-level command prompt, UAC will tell the user using UAC's
    own dialog box, and as I mentioned previously, Windows knows which areas of
    the screen are occupied by the user-level process' windows and dialog boxes
    and which areas are occupied by the UAC dialog box (and supposedly the user
    also knows, due to the dimming of the screen, though this notification
    mechanism is a kludge and ought to be fixed), so the user-level process
    can't fool the user into clicking the wrong button in the UAC box.
     
    Roof Fiddler, Oct 31, 2006
    #11
  12. Pirate Pete

    Jimmy Brush Guest

    This is how things appear; however, this is not technically accurate. What
    you see dimmed is actually a screenshot of the other desktop, not the actual
    desktop. The desktops are actually seperated VERY well; they cannot mix as
    you suggest.

    In any case, this is not really necessary - In Windows Vista, programs
    running in a higher privilege level are seperated pretty good from
    lower-privileged applications, so this point is no longer relevant to the
    discussion - the speration you are after is already present without needing
    different desktops.

    UAC prevents applications from doing things that the user does not have
    explicit permission to do, but the administrators group does. UAC then asks
    the user if they want to invoke their admin power to complete the operation.

    The user is explicitly allowed to customize their shell and generally change
    anything on the system that only affects their user account, so that does
    not prompt UAC since the user has access. This is how it is different - the
    shell only affect the user, while other UAC-protected settings affect the
    entire computer.

    OK - at this point you have came up with a valid solution - The shell could
    run privileged, and all shell plugins ALSO would have to run as privileged.

    However, this does leave one problem unsolved: the problem of non-elevated
    applications using the file/open dialogs. You would have to compromise
    here, by re-designing the file/open dialogs and other shell code that must
    run from a non-elevated process to also run non-elevated, and ask the user
    for permission whenever it wants to transition to do an elevated task (which
    is the current behavior and what you are trying to avoid).

    Yes it does. The shell must either be ran COMPLETELY as an administrator -
    including any components that must interact with it - or COMPLETELY as a
    standard user. If you mix the two, how is the non-elevated shell going to
    execute elevated tasks? It cannot (without introducing security risks and/or
    annoying permission prompts for the user whenever this type of transition
    occurs - which is what you are trying to avoid in the first place).

    So, let me summarize what your computer looks like at this point:

    - The shell runs as admin
    - Anything that hooks into the shell runs as admin without prompting the
    user for permission (but the user has to approve this hook-process to
    happen: things just cant hook into the shell by themselves without user
    permission, but once they're there, they're there)
    - Any normal program that uses shell components gets a watered-down shell
    that cannot do privileged things (basically reverts back to the way the
    shell works right now- by prompting the user when it needs privilege)

    Benefits:

    - The shell is now trusted and runs seperate from lower-level processes.
    This lets it do some fun stuff, like override UAC behavior in certain
    circumstances.

    Disadvantages:

    - Much more code is running elevated by default. This is always a bad thing.
    Programs should only run with the privileges they need - and 99% of the time
    the shell does not need admin privileges.
    - Continuing on the previous point, how many security vulnerabilities are
    rooted in either the shell itself or a file that is used by the shell?
    Keeping the shell running as admin means these security vulns continue to
    plague Windows users.
    - Approved shell plugins now run as admin, automatically, whenever you start
    your computer, and without prompting the user. *shudder*.
    - You don't get the benefit of the privileged shell in common dialogs and
    other shared shell code that must be able to run in non-privileged
    processes.
    - You still don't get this bypass-UAC behavior you are looking for when
    other programs run a program at the user's request - this nice feature will
    only work when running applications say from the start menu or desktop.

    I see way, way, way more disadvantages than advantages in this scenario. I'm
    sure microsoft thought about these same sort of things when they decided to
    make the shell run as unprivileged.

    Me:
    You:
    It's not HOW the two are connected that is the problem - it is the EXISTANCE
    of a connection at all. Let me show you what I mean in the context of your
    example.

    In this example, HOTMAIL is "elevated" - it has access to everyone's email.
    And, your WEB BROWSER is non-elevated - it should only have access to YOUR
    e-mail.

    You are crafty and find a bug in hotmail ... say you just change the
    username in some part of the URL and you can magically read other people's
    e-mails ... BINGO! Your non-privileged WEB BROWSER is now executing
    PRIVILEGED actions - reading other people's e-mail.

    This is what I am talking about - if you allow a process with a higher
    privilege to talk to a process with a lower privilege (the scenario I was
    referring to here was what would you would need to do if you made shell
    plugins NON-privileged but the shell PRIVILEGED), it opens up this type of
    attack.

    This is a security vulnerability because of a leaky abstraction - you have
    defined two different things (elevated vs. non-elevated), but are breaking
    the abstraction in order to allow a certain feature to work (by not
    enforcing this abstraction by allowing these two different things to merge
    using this magic interface).

    I said:
    I am not talking here about identifying specifically if the user is clicking
    a certain button - I am talking about Windows knowing that the user is
    INTENDING to run a program.

    The problem here is knowing WHEN to bypass UAC in a third-party program and
    when NOT to. Windows simply cannot figure this out. Windows can know when it
    is sending UI - but it can't know what the user INTENDS to do.

    If you enable bypassing UAC based soley on when the user is performing some
    kind of UI, then programs will take advantage of this behavior and render
    any benefit you have gained with UAC useless.

    For example, by popping up a message box and then taking advantage of the
    UAC-bypass behavior when the user closes the dialog - Windows knows the user
    is responding to UI, so it enables the UAC-bypass behavior, even though the
    user is not INTENDING to run a program.

    Thanks so much for bringing this up - I have learned a lot through this
    discussion.
     
    Jimmy Brush, Nov 2, 2006
    #12
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.