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

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

• .Net Nemo

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

• Crasch

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

  
  
  

• FreddyHalim

  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
  
  

• ReiXou

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

• best49erfan

  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

  
  

• Yahweh

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

  
  

• ITfJ

  [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
  
  

• Hermit Dave

  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

  
  
  

• Mr.Bean

  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

  
  

• Dato0011

  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.

• andien_geo

  > 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
  

• Cuneyt Deger

  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

  
  

• viliescu

  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.
  

• Vivek Natani

  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
  
  
• [BUG] Vista doesn't start application called "install" w/o being elevated.