Why won't my EXE run under Vista with UAC Enabled?

Discussion in 'Windows Vista Security' started by Joseph Geretz, Feb 26, 2007.

  1. My application is comprised of a number of discrete deployment artifacts:

    1. A bunch of ActiveX DLL's
    2. The Main Application Executable (MainApp)
    3. AutoUpdater - ActiveX EXE
    4. A variety of utlity applications.

    Everything runs fine with UAC disabled. With UAC enabled, I encounter the
    following issues:

    1. The main application launches, however it fails when it attempts to
    create an instance of the AutoUpdater:

    Automation error: The requested operation requires elevation.

    2. When running the AutoUpdater directly from the Windows shell, I get the
    User Account Control dialog: An unidentified program wants access to you
    computer.

    Unidentified??? Why is this specific executable any more unidentified than
    the rest of my application? My application ships with a number of associated
    utility application as well as the main application executable. All of these
    launch just fine at the user's request. Why is this program specifically
    singled out as suspicious when launched directly by the user, and to require
    elevation when launched programatically as an ActiveX server?

    BTW, we deploy another utility application which is also constructed as an
    ActiveX EXE and this one runs just fine, raising no flags at all, whether it
    is run directly from the Windows shell, or whether it is launched
    programmatically from a client program. So what is it about the AutoUpdater
    specifically which cause problems? Having unleashed UAC on us, does
    Microsoft provide any guidelines, or any tool which can analyze a program or
    its Source and make recommendations about what will require elevation?

    Thanks for any advice which you can provide.

    - Joseph Geretz -
     
    Joseph Geretz, Feb 26, 2007
    #1
    1. Advertisements

  2. Joseph Geretz

    kpg Guest

    Mostly to commiserate, but perhaps my apps behavior will shed light on
    this issue for someone that understands such things:

    I have an app that calls (shells) to other apps as follows:

    Launcher.exe -> main.exe <-> updater.exe

    (The shelled from app terminates in each case. so only one instance
    is running most of the time)

    That is, Launcher is run by the user, it launches main, then on
    occasion the user will update, so main shells to update, then
    terminates, when complete, update launches main (then terminates).

    Now, launcher can shell to main, the only problem (when UAC
    is on) is that Main cannot shell to updater, however, if updater is
    called directly, it can shell to main, then main can shell to updater.

    So on the surface, it looks like only one level of shelling is being
    allowed - but that could just be a coincidence.

    kpg
     
    kpg, Feb 26, 2007
    #2
    1. Advertisements

  3. Hi kpg,

    Thanks for your response.

    Your situation is somewhat similar to my own. In our case, MainApp.exe
    creates a running instance of AutoUpdate.exe.

    (AutoUpdate is an ActiveX EXE; in this case running as a server to MainApp,
    but also capable of running directly from the Windows shell)

    Here is the specific line of code which is failing:

    Set Agent = CreateObject("AutoUpdate.Agent")

    Since AutoUpdate is an ActiveX EXE, the creation of the class instance
    triggers the creation of a new process, which for whatever reason requires
    elevation.

    OK, so SRSAutoUpdate requires elevation. I don't know why, but for now I'll
    take that as a given. Here is some additional information.

    If I run MainApp as Administrator, then I get the dialog, unidentified
    program, blah blah blah. However, after I respond to the dialog, the
    application runs properly. It's clear that once MainApp is trusted for
    elevation, it is capable of launching a secondary process which requires
    elevation.

    OK, so we're getting places. I don't want users to have to deal with
    explicitly requesting administrative priviledge to run the application. So I
    created the following manifest file:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <assemblyIdentity version="5.2.0.22"
    processorArchitecture="X86"
    name="MyApp.exe"
    type="win32"/>
    <description>elevate execution level</description>
    <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
    <security>
    <requestedPrivileges>
    <requestedExecutionLevel level="requireAdministrator"
    uiAccess="false"/>
    </requestedPrivileges>
    </security>
    </trustInfo>
    </assembly>

    I named this MyApp.exe.manifest and dropped it into the application folder.
    Supposedly, this should achieve the same result as manually requesting Run
    as Administrator, but this doesn't have any effect. Any idea why not?

    Thanks for any advice which you can provide!

    - Joseph Geretz -
     
    Joseph Geretz, Feb 26, 2007
    #3
  4. AAAAAAaaaarrrrggggggghhhhh!!!!!!

    It's the NAME of the executable, AutoUpdate, which makes Vista THINK
    (assuming
    that this brain-dead OS is capable of such a thing) that the process needs
    to run elevated.

    kpg, this explains your issue as well; In your case it's that third app in
    the chain which has the magical term 'update' in it, for me it's the second.
    Who the !#$%@$# slapped this so-called OS together, J.K. Rowling?

    :-(

    Joseph Geretz
     
    Joseph Geretz, Feb 26, 2007
    #4
  5. Joseph Geretz

    Jon Guest

    That was a good find. Appears to apply only to the .exe extension (eg
    update.dll is fine). I wonder if there are any other keywords like that to
    avoid.

    May help others that are having problems with software that includes an
    updater.
     
    Jon, Feb 26, 2007
    #5
  6. Joseph

    These newsgroups are typically for end users of Windows. Have you tried
    posting this question to the developer forums? This is where the application
    developers congregate and there are many Microsoft employees and independent
    developers that post to those forums. There is likely someone there who has
    already worked their way through, and found a solution, for the problems
    that you are having.

    MSDN Forums:
    http://forums.microsoft.com/MSDN/default.aspx?SiteID=1
     
    Ronnie Vernon MVP, Feb 26, 2007
    #6
  7. Thanks Ronnie,

    Actually, I crossposted this (ooohhhh!) to vista.security.

    Anyway, I've got the problem figured out. I used the literal string 'Update'
    as part of the name of my executable without getting permission from my
    Mommy. This caused Vista to panic. Very sophisticated security algorithms in
    place I see. Based on the filename.

    Sheesh!

    - Joseph Geretz -
     
    Joseph Geretz, Feb 26, 2007
    #7
  8. Joseph Geretz

    Robert Firth Guest

    Magic keywords "setup", "update"...

    Old installers were not written properly to ask for proper permissions to
    install an app (admin privileges). To get around the hassle of having to
    manually right click on virtually every installer and select "Run as
    Administrator" forced them to search for those keyworks in the .exe name and
    auto-elevate (actually auto-ask to elevate).

    --
    /* * * * * * * * * * * * * * * * * *
    * Robert Firth *
    * Windows Vista x86 RTM *
    * http://www.WinVistaInfo.org *
    * * * * * * * * * * * * * * * * * */
     
    Robert Firth, Feb 27, 2007
    #8
  9. Joseph Geretz

    Robert Firth Guest

    Based on filenames and wheter or not you asked for administrative
    privileges. If it is an application setup, it will need administrative
    privileges to write to c:\program files. Therefore, it makes since to
    auto-elevate setup programs - assuming you trust the developer.

    --
    /* * * * * * * * * * * * * * * * * *
    * Robert Firth *
    * Windows Vista x86 RTM *
    * http://www.WinVistaInfo.org *
    * * * * * * * * * * * * * * * * * */
     
    Robert Firth, Feb 27, 2007
    #9
  10. The old it ain't Microsoft's fault excuse. Interesting, that seems to
    be more a MVP excuse considering what high ranking Microsoft officials
    admit to:

    Item: Jesper Johansson, a senior security strategist in the Security
    Technology Unit at Microsoft, admits that the current implementation
    of UAC presents too many privilege escalation pop-up prompts, but he
    insists there is a method to the apparent madness.

    "Unless we get feedback on what works and what does not, we can't fix
    it. If you disable critical technologies that we are trying to get to
    work, we can't fix them," Johansson said in a blog entry. "That means
    that, yes, some things will be annoying and not work quite right in
    the final release, unless people work with us to fix them," he added.

    Item: Microsoft has granted, in a roundabout way, that Vista has 'high
    impact issues.' It has put out an email call for technical users to
    participate in testing Service Pack 1, due out later this year, which
    will address 'regressions from Windows Vista and Windows XP, security,
    deployment blockers and other high impact issues.'

    It's hard to know whether to be reassured that Service Pack 1 is
    coming in the second half of 2007, and thus that there is a timeframe
    for considering deployment of Vista within businesses, or to be
    alarmed that Microsoft is unleashing an OS on the world with "high
    impact issues' still remaining, according to Microsoft.
     
    Adam Albright, Feb 27, 2007
    #10
  11. Magic keywords "setup", "update"...
    And so we sink to the lowest common denominator. Instead of actually
    detecting operations which require elevation, Vista take the extremely
    sophisticated approach of string detection on the filename!!!???

    You're not seriously suggesting that this is a serious OS implementation,
    are you?

    - Joseph Geretz 0
     
    Joseph Geretz, Feb 27, 2007
    #11
  12. Joseph Geretz

    DevilsPGD Guest

    In message <> "Joseph Geretz"
    Fair enough -- Do you have a better suggestion that maintains backwards
    compatibility?
     
    DevilsPGD, Feb 27, 2007
    #12
  13. Fair enough -- Do you have a better suggestion that maintains backwards
    Yes, as I suggested:

    But that's too tricky?

    - Joseph Geretz -
     
    Joseph Geretz, Feb 27, 2007
    #13
  14. Adam

    I don't see anything in that quote that conflicts with the statement that
    you see as an excuse. The users are the people who need to put pressure on
    the developers to follow the current Microsoft standards for writing
    applications and programs for Vista. These program developers have had more
    than ample time to respond to the many calls by Microsoft to learn and
    follow the new programming guidelines.

    We all knew that the changes in Vista would be "high impact issues" but the
    overwhelming reason was the state of the security in previous versions. UAC
    is not going to go away in SP1.
     
    Ronnie Vernon MVP, Feb 28, 2007
    #14
  15. the developers to follow the current Microsoft standards for writing
    All right, I'll call you on it, and if you can help me out or point me in
    the right direction, I'll be grateful for your help.

    What are the guidelines for deploying and registering an ActiveX EXE on
    Microsoft Vista with UAC enabled?

    Simple question. I'm one of the devleopers you speak of, and I very much
    wish to follow the new programming guidelines. It's one thing to talk about
    guidelines, and quite another to actually define and publish them. I've been
    Googling and asking questions for days now, trying to find out what the
    guidelines are for deploying ActiveX EXE with UAC enabled. So please, what
    are the guidelines?

    Thanks,

    Joseph Geretz
    Microsoft VPD
    Very Pissed Developer!
     
    Joseph Geretz, Feb 28, 2007
    #15
  16. Joseph

    Here are some links to get you started.

    Developer Best Practices and Guidelines for Applications in a Least
    Privileged Environment:
    http://msdn2.microsoft.com/en-us/library/aa480150.aspx

    Look near the bottom of this link for a downloadable help file on developing
    ActiveX Controls for Vista.
    Windows Vista Application Development Requirements for User Account Control:
    http://msdn2.microsoft.com/en-us/library/aa905330.aspx

    Security in Longhorn: Focus on Least Privilege:
    http://msdn2.microsoft.com/en-us/library/aa480194.aspx

    You can access the Vista Developer forums here and dialog with other
    developers who doing the same work that you are.
    http://msdn2.microsoft.com/en-us/windowsvista/aa905020.aspx

    Google Search:MSDN2
    http://tinyurl.com/2kq25h
     
    Ronnie Vernon MVP, Mar 1, 2007
    #16
  17. Hi Ronnie,

    Unless I missed it, the questions of installing an ActiveX EXE is *not*
    addressed in any of the links you reference. Your allusion to developers who
    are not following 'Microsoft guidelines' is nothing more than apologetics
    for Microsoft's abysmal practice in this regard. Microsoft has changed the
    rules of the game radically, without fully considering all of the
    implications and without providing developers with adequate documentation.

    So again, I challenge you. Where is the documentation, the guideline if you
    will, on how to install an ActiveX EXE using a custom action from within an
    MSI setup file? Not from within an EXE setup file, that will work - but from
    an MSI setup file. Although, why an MSI should operate under different rules
    than the equivalent EXE is beyond me, but no doubt you can cite a
    'guideline' which will explain this to us?

    - Joseph Geretz -
     
    Joseph Geretz, Mar 1, 2007
    #17
  18. Joseph Geretz

    Guest Guest

    My understanding is the manifest (this type of manifest) must be in the exe.
    Everything I've read says to put in exe. There is no mention of other ways
    (incl warnings). I suppose it stops people dropping manifest files about
    allowing elevation of other's programs..
     
    Guest, Mar 1, 2007
    #18
  19. My understanding is the manifest (this type of manifest) must be in the
    How do I put the manifest 'in the exe'? Can you please elaborate on how to
    do this?

    Thanks!

    - Joseph Geretz -
     
    Joseph Geretz, Mar 1, 2007
    #19
  20. Joseph Geretz

    Guest Guest

    With a compiler. I guess the intent is the program vendor does it.

    You could try, if you don't have a Resource Compiler (what language do you
    write in - VB even has one), something like Resource Hacker (search on
    google) which decompiles and recompiles resources in executables.

    Also I didn't follow the links someone else gave you, but I thought the
    following was mentioned on them - just in case not, MS has a tester for
    programs that indicate if it may run into problems (and what problem). It's
    a related download to App Compatability Kit. It runs your program and see's
    what it does.
     
    Guest, Mar 1, 2007
    #20
    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.