We recently launched the iTOK HelpDesk R3 for all the wonderful supporters of iTOK. The new application has an integrated mini-app which removed a lot of complexity of the old application by setting up the customer account on its first use. This little wizard is not a setup application, its just called helpdesksetup.exe and is invoked from the helpdesk.exe core application when it cannot get login details.
The release of the HelpDesk R3 was released at the same time as the release of Vista. We have performed testing with several of the Microsoft release candidates to ensure compatibility prior to its deployment, but it certainly was not the focus of our testing. The testing did all seem to go well, so we finally went live. Then something strange happened. On Vista, the first time the application was run would throw up a UAC dialog. This never happened on the release candidates we had tested on and I was shocked. There was no reason this executable should throw a UAC dialog – it didn’t need admin privlegdes!
After much brow beating and consternation I accidentally stumbled upon the answer. I was listening to the fabulous PodCast called Security Now by Steve Gibson and Leo Laporte and I heard about the kludge which is how UAC treats installers… it checks the executables filename to determine if it should throw up the UAC dialog before executing it – even without knowing what the installer does.
h-e-l-l-o
All of a sudden the pieces fell in to place. If I simply RENAME MY EXECUTABLE it will no longer bring up the UAC dialog. I’m sorry, but that is pretty lame for a uni undergrad project let alone a commercial operating system.
[UPDATE]
There was another article on this issue in The Register which sparked furious debate. There is a comment and trackback to this article in there.
I had another thought as I was driving home today. I wonder if I wrote a malware installer and called it “s etup.exe” or “set-up.exe” or some other non-obvious permutation it would still be trapped by UAC? If not then we have lots to fear…
It shouldn’t be a problem if the malware installer hides its intentions. Installers have to run with admin priviledges in order to be allowed to write files to certain protected places. Without the UAC granting this level of access the unrecognized installer would not be able to complete the installation.
Steve, I see what you’re saying and I had been thinking of this issue in reverse. If I write an installer and its not UAC aware then I would still want UAC to give it admin control (hence throw up the dialog) so that it doesn’t fail. Therefore the string comparison on filename may be an option (still don’t like this approach though) to try and get the most application installers to work.
If I manage design an installer for malware which doesn’t throw up a UAC confirmation I need to make sure that my attack surface is still exposed to non-UAC-admin users, which in theory should be more limited. In reality you can still do a few admin style things like write to HKLM registry space without being a ‘UAC administrator’ using the default Vista user credentials.