none
[BUG] Vista doesn't start application called "install" w/o being elevated. RRS feed

  • Question

  • Hi,

    I just encountered this really strange behaviour, which is definitely a bug in Vista.

    Consider the following situation. You're logged in as an administrator account.
    Start a CLI shell of your choice, start it normally, so that it's running non-elevated.

    Now consider a console application called install.exe. It's neither a GUI application,
    nor is it an installer application in the Windows sense. It's just called install.exe. In my
    case it's part of GNU coreutils and it's called install because it's usual task is to install
    software on the system. However, it's perfectly valid to call install as normal user and
    use it to install stuff into a subdirectory on which you have permissions. This is what
    happens when running under Cygwin (processes are created using CreateProcess):

    $ which install
    /usr/bin/install
    $ /usr/bin/install
    bash: Permission denied.
    $ strace /usr/bin/install
    strace: error creating process C:/cygwin/bin/install, (error 740)
    $ net helpmsg 740

    The requested operation requires elevation.

    $ mv /usr/bin/install.exe /usr/bin/huh.exe
    $ /usr/bin/huh
    /usr/bin/huh: Missing file operand
    Try `/usr/bin/huh --help ' for more information.
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    This is the expected output.

    The same bug occurs when the file is called, for instance, instal.exe, ginstall.exe,
    instalx.exe, setup, vsetup, or even this-is-not-an-installer.exe. It does not occur if the
    file does not contain the substring "instal" or "setup".

    I can't believe that this is honestly meant to occur. You can't require elevation just
    because the application happens to contain a specific substring in its name. This
    is a serious bug in my eyes.


    Regards,
    Corinna
    Tuesday, December 12, 2006 4:05 PM

All replies

  • Tuesday, December 12, 2006 9:32 PM
  • I had similar feelings about this feature   It is intended to elevate legacy installer applications.
    Wednesday, December 13, 2006 3:19 PM
  • Corinna,

    it seems to me that porting cygwin tools has become harder as of Windows Vista. If Microsoft is not willing to retract this heuristics (guess what's going to happen), the official MS way is to add a manifest specifiying the desired elevation level to the affected Cygwin executables.

    I Wonder if there's port of "install" in Microsoft's SFU, and how MS is willing to deal with it.

    Good luck,

    Juergen

     

    Wednesday, December 13, 2006 7:34 PM
  • An alternative workaround would be for Cygwin to use ShellExecute instead of CreateProcess. That will result in getting an elevation prompt for your install.exe (with no manifest). That is probably what you want anyway for a program that installs stuff - and thus probably needs to have elevated permissions.
    Wednesday, December 13, 2006 8:02 PM
  • Or you can turn off that specific feature:
    secpol.msc -> Security Settings -> Local Policies -> Security Options ! UAC: Detect application installations and prompt for elevation

    Thursday, December 14, 2006 1:05 AM
  • [This is going to be long, please bear with me.  I'm going to reply to all postings in this
     thread in one go for clarity.]

    I don't know how others see this but IMHO this is a mistake in the UAC design.  I can't
    understand how a serious design can handle executables differently, just because they
    happen to have some arbitrary substrings in their name.
    Using this sort of "heuristic" is
    bound to result in trouble.

    Substrings like "instal", "setup" or "update" are in no way sure signs of an application
    installing something on the system which requires special privileges.  What about
    entirely harmless applications like, say, an application with embedded SQL statements
    in it, naturally named "update-customer.exe"?

    How are different native languages supposed to be handled?  Does the system only
    recognize applications as installers which are using the english language substrings?
    Or do french, german, italian, japanese versions suffer from a greater set of unexpectedly
    forbidden filenames?  How about native languages in which entirely normal words contain
    substrings like "instal", not having anything at all to do with installing software?

    How are developers supposed to learn about these forbidden filenames?  The document
    you provided a link to (thanks, btw) reads:

     
    Filename includes keywords like "install," "setup," "update," etc.

    What exactly is "etc." in, say, gaelic?

    georgekue wrote:
    > If Microsoft is not willing to retract this heuristics (guess what's going to happen), the
    > official MS way is to add a manifest specifiying the desired elevation level to the affected
    > Cygwin executables.

    Right, but, oh well, an application manifest just to tell the system "hey, sorry, but I'm just
    *named* install.exe, I don't *have* to run elevated".  I'm not (yet?) fluent with how to create
    a manifest, but from what I read so far I'm wondering how one creates such a manifest with
    gcc and friends???

    There's another point to that.  I'm not the maintainer of coreutils as part of the Cygwin net
    distribution.  This package is maintained by a volunteer from the net, as are 98 % of the
    roughly 800 packages in the distro.  I can't tell them they have to produce application
    manifests if they are unlucky enough to have executables with specific substrings in the
    name in their package.  Not to mention the additional burden of convincing the upstream
    maintainers that this patch is actually necessary.

    efratian wrote:
    > An alternative workaround would be for Cygwin to use ShellExecute instead of
    > CreateProcess.

    This is not feasible.  How is that supposed to work in bash scripts?  What about
    `make install' calls which are using coreutil's install quite excessively.  These `make install'
    calls don't require any special privilege since they are usually used to install into paths
    which are writable to the current user anyway.  A typical example is using the DESTDIR
    make variable to install into a temporary path, preliminary to creating a binary package for
    the distro.  It's not seldom to have 20 and more calls to /usr/bin/install in one `make install'
    run.

    And, to make it worse, what about users trying to run `install' within an OpenSSH session
    from a remote machine.

    Eric Perlin wrote:
    >
    Or you can turn off that specific feature: secpol.msc -> Security Settings -> Local Policies
    >  -> Security Options ! UAC: Detect application installations and prompt for elevation

    Yes, *I* can do that and I know how to do that, but we're not talking about my machine.
    We're talking about the users of Cygwin which already get stuck right from the beginning,
    when the /etc/profile script tries to copy the files from /etc/skel into the new user's home
    directory.  If they accidentally start their first shell non-elevated, they get a couple of
    "/bin/bash: /usr/bin/install: Permission denied." message for no apparent reason, and
    installing the skelton files fails.

    I guess the effect is obvious:  The cygwin user's mailing list will get the support burdon
    for this.  Consequentially a FAQ entry will be created at one point, saying "switch off this
    feature using secpol.msc, yada yada yada" and the mailing list gurus will point each new
    complaining Vista user to this FAQ entry.  And that's just the Cygwin community.  I don't
    want to know how many other, quite standard commercial applications will break because
    of this and how many support hours this will cost.

    Note that I don't say that the whole "Detect installer apps" is useless, but trying to recognize
    (real) installers by substrings in their name is a really big mistake.


    Regards,
    Corinna
    Thursday, December 14, 2006 3:09 PM
  • > trying to recognize (real) installers by substrings in their name is a really big mistake

    This is not a mistake. This is The Microsoft (R) Way (TM).

    Thursday, December 14, 2006 3:58 PM
  • Installer Detection only applies to:

    1. 32-bit executables

    2. Applications without a requestedExecutionLevel

    3. Interactive processes running as a standard user with UAC enabled

    Before a 32-bit process is created, the following attributes are checked to determine whether it is an installer:

    ·      Filename includes keywords like "install," "setup," "update," etc.

    ·      Keywords in the following Versioning Resource fields: Vendor, Company Name, Product Name, File Description, Original Filename, Internal Name, and Export Name.

    ·      Keywords in the side-by-side application manifest embedded in the executable.

    ·      Keywords in specific StringTable entries linked in the executable.

    ·      Key attributes in the resource file data linked in the executable.

    ·      Targeted sequences of bytes within the executable.

    Note

    The keywords and sequences of bytes were derived from common characteristics observed from various installer technologies.



    What are the chances that someone from Microsoft will define what the keywords are?

    Looks like trial and error, I guess.


    Thursday, December 14, 2006 6:17 PM
  • Corinna,

    I agree with you that heuristics are always bad. What MS did here was to establish a way to make sure that old-style Windows installers get the access rights they "usually" need without granting all processes the standard administrative permissions they had until Windows Server 2003.

    Since you are fluent with UNIX, you'll see that as of Win2k, Windows systems could have been used like Unizes, i.e. users work with restricted permissions and only sometimes do privileged tasks with a sudo-kind of mechanism. Unfortunately, and I think the security guys at MS don't like this either, many third-party application programmers (and the installers they wrote) did not care about that.

    MS is stuck with this situation until now, and the UAC is their way of trying to make Windows more secure. Still, there are tens of thousands of third-party installers out in the wild which need admin rights to execute, but do not have a manifest (because this is new to Vista). My guess is that, from Microsoft's point of view, it's Vista compatibility of one product (cygwin) against thousands, and they opted for the thousands.

     Corinna Vinschen wrote:

    Right, but, oh well, an application manifest just to tell the system "hey, sorry, but I'm just
    *named* install.exe, I don't *have* to run elevated".  I'm not (yet?) fluent with how to create
    a manifest, but from what I read so far I'm wondering how one creates such a manifest with
    gcc and friends???


    There are similar issues with Java and gcj (gcc for Java), where there is also a manifest file to be supported, but still isn't. Seems to me that gcc for the Windows platform should learn how to take into account Windows manifest files, beacuse it's a Windows platform particularity.

    Regards,

    Juergen

     

    Friday, December 15, 2006 10:19 AM
  • Hi Juergen,

    > UAC is their way of trying to make Windows more secure

    sorry, but I disagree here in a certain way.  I agree that UAC is one way of making the
    system more secure, but the part of UAC called "Installer Recognition" is by no means
    a facility which makes Windows more secure.

    It's a convenience feature and nothing else.

    The situation is quite simple.  All user accounts including the admins are running
    under lower privileges.  If you double-click an installer application, nothing bad
    can happen, because it has no privileges.  So far for the security impact.

    However, there is a way to run an installer with full admin privileges.  It's right-click ->
    "Run as administrator".  So, what's the gain of the installer recognition?  Convenince.
    You can just double-click an installer application instead of switching your brain on! 

    What's really ugly is the fact that an unknown number of quite harmless applications
    suffer from the installer recognition, just so that the user doesn't have to think.

    This is still a really big mistake, IMO.


    Corinna
    Friday, December 15, 2006 12:00 PM
  • Oh and, I forgot to mention that this might even have a *negative* security
    impact.  Applications with "bad" keywords in their name have to run with
    elevated admin privileges, just because the system forces to run them
    with elevated privileges.  There's *no* technical requirement to run these
    applications with elevated privileges.  Consequentially, more applications
    are running elevated than actually necessary.

    And, there are so many installers out there that the non-thinking user
    will become quite tired of all this "This application needs admin privs..."
    dialogs that the user either switches that feature off, or will click on "OK"
    quite automatically.

    How long, do you think, will it take, until malware will use this feature in a
    simple social engineering attack?


    Corinna
    Friday, December 15, 2006 12:08 PM
  • Hi Corinna,

    > Oh and, I forgot to mention that this might even have a *negative* security
    > impact.  Applications with "bad" keywords in their name have to run with
    > elevated admin privileges, just because the system forces to run them
    > with elevated privileges.  There's *no* technical requirement to run these
    > applications with elevated privileges.  Consequentially, more applications
    > are running elevated than actually necessary.

    good point - just pack your favourite malware into a setup.exe, hope for the user to confirm the UAC dialog, and bingo!

    Regards,

    Juergen

    Friday, December 15, 2006 12:54 PM
  • > good point - just pack your favourite malware into a setup.exe, hope for the user
    > to confirm the UAC dialog, and bingo!

    Yep.  And the next step, computer magazines providing "1000 Vista tricks", telling
    the uninitiated user they can get rid of the annoying dialogs by setting the Admin's
    UAC setting from "Ask for consent" to "Elevate w/o prompting", thus allowing
    every application called "install", "setup" or "update" to run elevated.  What a
    simple way to provide Administrator rights for the virus next to you.

    Anybody here still convinced that "Installer recognition" is a security feature?


    Corinna
    Friday, December 15, 2006 1:22 PM
  • I know I'm gonna name my next virus/worm install.exe!
    Friday, December 15, 2006 1:49 PM
  • http://www.gnu.org/software/binutils/manual/html_chapter/binutils_12.html

    windres seems to be the binutils tool for adding resources to pe executables.

    As far as other options, a manifest can always be stuck next to an executable if it can't be rebuilt.

    e.g.:

         install.exe

         install.exe.manifest   (specifying requestedExecutionLevel="asInvoker")

    I would strongly reccommend against trying to rename the files to work around InstallDetection, as there are factors beyond just the filename.

    Friday, December 15, 2006 8:26 PM
  • Hi David,

    I played around with manifests in the meantime and it's no problem to link a manifest
    to an executable using windres.

    However, the above method of just adding an install.exe.manifest file to the directory
    in which install.exe resides, doesn't work for me.I tried to use the normal text file
    containing the manifest source, as well as a binary representation created with
    windres, same way as when linking it to the executable.  Both versions had no effect.

    So, well, how do I create such a mainfest file like you suggest?


    Thanks,
    Corinna
    Friday, December 15, 2006 9:09 PM
  • The presence of the manifest may be cached - if you use something like 'touch' to modify the timestamp on install.exe, it'll probably pick it up next time you run it.
    Friday, December 15, 2006 9:29 PM
  • That did it.  Thanks for the hint!  This is very helpful to know.


    Corinna
    Friday, December 15, 2006 9:57 PM
  •  David Tyler Hunt wrote:

    http://www.gnu.org/software/binutils/manual/html_chapter/binutils_12.html

    windres seems to be the binutils tool for adding resources to pe executables.

    As far as other options, a manifest can always be stuck next to an executable if it can't be rebuilt.

    e.g.:

    install.exe

    install.exe.manifest (specifying requestedExecutionLevel="asInvoker")

    I would strongly reccommend against trying to rename the files to work around InstallDetection, as there are factors beyond just the filename.



    But this doesn't work as a fix for this particular problem.  My company has exactly this issue - we have two update tools for our suite, and they send data around our own communication system about newly loaded projects, they certainly do not need any kind of administrator privilege.  But because they are named in the wildcard style "*update*.exe", they demand to be elevated, whether I have a manifest there or not.  If I set the <requestedExecutionLevel> to level="asInvoker" in a manifest, it just stops the request to elevate - but still pops up a box telling me that the application cannot run because it needs elevation.  This is pretty brain-dead behaviour.  I cant even tell windows that this _doesn't_ need to elevate, so not to bother trying.

    The whole heuristics seems to be based on the filename only, because:

    - I took _all_ the code out of the executable, did a build [leaving just a main(...) that returned 1] and it still asked for elevation.
    - I renamed the old executable, replacing (literally) the 'update' with 'nothing', and with no manifest it worked without any requests to elevate.

    So what do I do now?  I cant change the executable filenames very easily, as this software suite runs in the same guise for Windows, Linux, and Solaris, and interoperates across them all, and such a change is pretty complex, and would incur the kind of time and testing hits that I cannot afford to make.
    Wednesday, June 13, 2007 2:01 PM
  • If a manifest is in place and being correctly identified, you absolutely will not get prompted - all installation detection and application compatibilty support is disabled on applications that identify themselves as Vista aware. You may get caching issues if you previously had a identically named file that didn't have a manifest, which is perhaps what you are seeing here. Have you tried the version with the manifest on a fresh machine?
    Wednesday, June 13, 2007 3:28 PM
  •  AndyCadley wrote:
    If a manifest is in place and being correctly identified, you absolutely will not get prompted - all installation detection and application compatibilty support is disabled on applications that identify themselves as Vista aware. You may get caching issues if you previously had a identically named file that didn't have a manifest, which is perhaps what you are seeing here. Have you tried the version with the manifest on a fresh machine?


    I've not tried this on another machine - we currently only have a single vista machine which I'm using for the conversion work.

    I know it's not a caching problem, however.  I can change the behaviour by changing the manifest - with 'asInvoker' used, it pops up a box saying that the program needs to elevate, but does not give me an option to do so, only an OK box.  Any other setting and I get the standard elevation box.  I have had caching issues with the manifest, but this doesn't always happen, and a reboot seems to clear it.
    Wednesday, June 13, 2007 4:09 PM
  • A reboot won't work.  Use an elevated command prompt and a tool like 'touch.exe' to force the system to try and pick up a side-by-side manifest.  An embedded manifest is preferred over one dropped next to an executable, though, so it's possible you'll need to rebuild the exe with a new manifest if it already has one inside.

     

    'it pops up a box saying that the program needs to elevate' -  what pops up a box saying the program needs to elevate?

    Wednesday, June 13, 2007 8:23 PM
  •  David Tyler Hunt wrote:

    'it pops up a box saying that the program needs to elevate' - what pops up a box saying the program needs to elevate?



    This is the Windows Vista box asking for elevated privilege; it's not presented on Windows XP.

    I've got around the problem by embedding the manifests into the exe files with mt.exe.  I know there are issues with this tool, so I've got plenty of testing to do on XP, 2003 server and Windows 2000 which are our supported Windows platforms.  Plus all associated build environment changes.
    Thursday, June 14, 2007 12:04 PM
  • I'm just a novice. Can you tell me specifically how to fix it?

     

     

    Saturday, February 23, 2008 4:00 AM
  • The following article has some fairly detailed instructions on adding a manifest:

    http://msdn2.microsoft.com/en-us/library/bb756929.aspx

    If you have a non manifested application with a name that triggers elevation (setup detection) and it's not appropriate, you'll want to explicitly specify asInvoker as the level.

     

    Tuesday, March 4, 2008 1:18 AM