Program Names govern admin rights in Vista

It's not what you do, it's what you say you do


Developers have discovered that the name given to a Vista executable affects whether or not it will require admin rights to run.

Security experts said the feature might seem odd, but helps to catch out spyware.

Reg Reader Mike, a C++ developer, discovered the behaviour after spending days trying to work out why just some of his projects required elevation (admin rights) to be run on his Windows Vista machine. To his disbelief, Mike realised that the different properties were simply due to projects being named differently.

"If Vista sees that you have created a Microsoft Visual C++ project with install in the project name, then that .exe will automatically require Admin Rights to run. Create exactly the same project, but call it, say, Fred, and the problem disappears," he explained. "Vista's security isn't just concerned with what an .exe is doing to your PC, but what it's actually called."

Mr Executable

We put these points to Microsoft, which responded with a statement that explained why installation programs might need admin privileges to run but not why this changes depending on the name given to a project.

"Installation programs are applications designed to deploy software, and most write to system directories and registry keys. These protected system locations are typically writable only by an administrator user, which means that standard users do not have sufficient access to install programs. Windows Vista heuristically detects installation programs and requests administrator credentials or approval from the administrator user in order to run with access privileges. Windows Vista also heuristically detects updater and uninstallation programs. Note that a design goal of UAC [User Account Control] is to prevent installations from being executed without the user's knowledge and consent since they write to protected areas of the file system and registry," it said.

Secure coding specialist Fortify Software said Microsoft's Installer Detection technology acted as a screen against spyware. While imperfect, and odd in the way its behaviour is affected by the names given to project, the feature is better than nothing.

"The Vista feature you've run into is the equivalent of an airport metal detector," explained Dr Brian Chess, chief scientist at Fortify Software

Spyware is a big problem on Windows (yet another reason I have a Mac), and Vista takes steps to make spyware harder to write. By default, programs under Vista don't run with administrator privileges. By requiring administrator privileges to run something that looks like an installer, Vista is making it more difficult for a program to automatically throw some unsavoury gunk on to your machine without your knowledge.

He added that although the feature is imperfect and inconvenient, it's "better than nothing".

Clarification

Changing the name of a compiled executable doesn't change its properties. But different names during the app development process do have an effect, as Mike explains.

If I use Visual C++ to compile a program called, say, "Mikes Installer.exe", then Vista will popup the security message, drag'n'drop won't work (as it requires extra security rights), and if may app asks which version of the OS it's running on, then Vista will tell it that it's Windows XP.

If I recompile the app as "Mike.exe", then these problems all go away, and Vista correctly tells my app that it's running on Windows Vista. Simply renaming the file from "Mikes Installer.exe" to "Mike.exe" isn't enough to solve the problems. Vista still (somehow) knows that the original filename had install in it's name.

I wasn't simply trying to do some simple Microsoft-bashing. This is all simply all about the filename of your .exe's affecting the way they run in Vista. But the solution is to build your .exe files in Visual C++ with a different filename, or to add a Manifest .xml file, as some of your readers did mention.

Similar topics


Other stories you might like

  • RAD Basic – the Visual Basic 7 that never was – releases third alpha
    Spend your weekend wallowing in the good old days

    RAD Basic has edged a little closer to bringing Visual Basic 6 back to your PC with the release of 0.5.0 Alpha 3.

    We last looked at RAD Basic a year ago and soaked in a warm bath of nostalgia for a time when Windows applications could be knocked out with the same skills needed to persuade Sinclair or Commodore hardware to display naughty words in a 1980s computer shop.

    While Microsoft ditched Visual Basic 6 in favor of .NET and C# many years ago, there remain plenty of IT professionals who owe their career to the language and an abundance of lashed-up solutions still underpinning substantial chunks of the corporate world.

    Continue reading
  • Google shows off immersive maps, AR-flavored search, Pixel 7, and more
    Your essential de-hyped guide to what the Chocolate Factory teased at developer shindig

    Google IO Google I/O, the ad biz's annual developer conference, returned to the Shoreline Amphitheater in California's Mountain View on Wednesday, for the first time in three years. The gathering remained largely a remote event due to the persistence of COVID-19 though there were enough Googlers, partners, and assorted software developers in attendance to fill venue seats and punctuate important points with applause.

    Sundar Pichai, CEO of Google parent Alphabet, opened the keynote by sounding familiar themes. He leaned into the implied sentiment, "We're here to help," an increasingly iffy proposition in light of the many controversies facing the company.

    He said he wanted to explain how Google is advancing its mission in two ways, "by deepening our understanding of information so that we can turn it into knowledge and advancing the state of computing so that knowledge is easier to access no matter who or where you are."

    Continue reading
  • Half of developers still at screens even during breaks
    Going for a walk: Good. Doomscrolling: Bad

    What are your peers doing to stave off burnout? Research from Stack Overflow suggests about half of developers are still spending their breaks in front of a screen.

    The Q&A programming resource surveyed 800 devs, and found most of the top five things they do when they need a break involve screens: listening to music (46 percent), visiting Stack Overflow (41 percent), browsing social media (37 percent), and watching videos (36 percent).

    Actually talking with fellow humans did not make the top five, and 4 percent of respondents had some other outlet for stress (possibly angrily banging some really terse comments into the source).

    Continue reading

Biting the hand that feeds IT © 1998–2022