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

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

Answer 1

This is by design.
Look for installer detection in: http://download.microsoft.com/download/5/6/a/56a0ed11-e073-42f9-932b-38acd478f46d/WindowsVistaUACDevReqs.doc

Regards
Eric

Answer 2

I had similar feelings about this feature   It is intended to elevate legacy installer applications.

Answer 3

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

 

Answer 4

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.

Answer 5

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

Answer 6

[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

Answer 7

> 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).

Answer 8

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.

Answer 9

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

 

Answer 10

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

Answer 11

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

Answer 12

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

Answer 13

> 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

Answer 14

I know I'm gonna name my next virus/worm install.exe!

Answer 15

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.

Answer 16

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

Answer 17

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.

Answer 18

That did it.  Thanks for the hint!  This is very helpful to know.


Corinna

Answer 19

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.

Answer 20

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?

Answer 21

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.

Answer 22

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?

Answer 23

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.

Answer 24

I'm just a novice. Can you tell me specifically how to fix it?

 

 

Answer 25

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.