The Program.exe Problem
February 17th, 2007 by 
mb
A couple years ago I mentioned in a SecurityFocus column that Windows has a problem when you put a file named “program.exe” in the system root directory. The problem is basically in how it deals with spaces in paths that don’t have quotes around them. Anyone with the permissions to create a file in the root directory could create a malicious program that could escalate their privileges. Here’s an excerpt from that article:
Suppose that you want to run the following command:
C:\Program Files\Internet Explorer\iexplore
One cool thing about Windows is that although the path contains a space, it still runs the application fine, even if you don’t place quotes around the entire command and even if you don’t use the executable extension for iexplore.exe.
But how does Windows know where the program path ends and the program’s command line parameters begin? How does it know that the user isn’t trying to run a program named “C:\Program.exe” with the parameter “Files\Internet Explorer\iexplore?”
The problem is that it doesn’t know. It just starts at the beginning and tries finding an executable until it finds a match. So in this case, it will try these files every time you run the command:
C:\Program.exe
C:\Program Files\Internet.exe
C:\Program Files\Internet Explorer\iexplore.exe
Today I ran across the program.exe file I mentioned in the article and thought I’d try it out again. I placed program.exe in my root directory and rebooted. Sure enough, several programs showed up in the log file. Looking through my Registry, I noticed that there are still thousands of file paths that include spaces and don’t have quotes around them. Program.exe is just one of the many ways you could exploit this. If you were targeting a specific executable you could probably hide it somewhere else in the path. In fact, you could also exploit DLL files and COM components using the same technique.
Microsoft has been aware of this issue since Windows NT 4, and it affects every version of windows since then, but surprisingly few people have really exploited it. Microsoft added a check for “C:\Program.exe” at startup but there is a Registry key that turns off this check. This key is:
Key: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion
\Explorer\DontShowMeThisDialogAgain
Value Name: RogueProgramName
If you set this value to “no” then the dialog box will no longer pop up. Here’s the problem: it is a user key and is probably warning the user way too late. Many services and other components run long before a user logs in. A program that runs as a service could easily add that Registry key for all users on the system. The check is also largely insufficient because there are many other paths in the system where you could exploit this.
So what does my program do? Here’s a rundown:
1. It sets the “RogueProgramName” registry value to “no”
2. It logs the program’s parameters and user context.
3. It constructs a path to launch the original program
Download program.exe and place it in your system root directory. Run it once to set the registry key. Check back after a while, especially after a reboot, and see what it logged. The program will store its logs in a file called program.dat. The program isn’t that smart and there’s no error handling so don’t expect everything to work perfectly.
Note that you could also try this in other directories that have spaces in the name and might hold executables. Try renaming it to documents.exe to catch programs run from c:\documents and settings\. You could also rename it to common.exe and placing it under the Program Files directory.
Of course, with little effort this program could be modified to be much stealthier and do some very bad stuff. In fact, bad enough that this problem really should be addressed better than it currently is.
You can download the files here:
program.exe 19kb
VB6 Source Code 12kb
When your website is ready to be launched you should start looking for a quality web host to get a web space and that provides a variety of web hosting services and can help in the web site design of the company as well. One such good company is hostmonster. The rapid increase in the wireless internet servicesand dsl technology, web based businesses is becoming more and more common. Business communication has become cheap and flexible through the voip technology. No tag for this post.
Related posts
Posted in Application Security, Hardening, Malware, Tools | 
February 17th, 2007 at 12:56 pm
Thanks for this great explanation and these download files are great
February 17th, 2007 at 3:00 pm
The key is in “Anyone with the permissions to create a file in the root directory”.
Once you let someone to play with your root directory consider all security gone.
February 17th, 2007 at 3:19 pm
thanks this information is good.
February 17th, 2007 at 3:45 pm
Write access is disabled for regular users in the root directory. Administrators have to explicitly give their consent to any modification of this directory, by confirming a UAC prompt.
This means that, in Vista at least, this is a non-issue.
February 17th, 2007 at 3:49 pm
@KpyM: The problem is that windows is not rigorous about which pathes have to be escaped. The fact that you need sufficient permissions to exploit the hole is only secondary.
February 17th, 2007 at 4:19 pm
Wow. I knew Windows was bad, but the fact that problems like this one have persisted for OVER TEN YEARS is rather amazing to me.
The real solution is to switch to a better OS. Windows will never be anywhere near secure enough.
February 17th, 2007 at 5:57 pm
[...] I thought I would add a bit more to my original post to clarify the problem. Half of the problem is the way Windows searches paths, and the other half is software developers who don’t quote their paths in the Registry or when calling CreateProcess. There are no built-in Windows services that have this problem and this issue has been documented for over a decade. [...]
February 17th, 2007 at 8:23 pm
I never knew windows used such an appalling hack to locate executables. Adding a registry check for ‘program.exe’ is totally inadequate, as this problem exists for every occurance of a space in any directory name
Quite frankly, I’m glad I don’t use it.
February 18th, 2007 at 12:30 am
Thank God I use Mac OS X (Tiger) on an Apple
February 18th, 2007 at 8:30 am
It’s quite retarded what kind of hacks Microsoft uses to provide backwards compatibility with MS-DOS. I don’t think this is really exploitable though because if the root directory is world-writable you have a problem anyway. Also note that these path are localized in Windows, so it’s only “Program Files” in English versions.
February 18th, 2007 at 11:55 am
@Moritz:
Saying that the fact that you need sufficient permissions to do something is only secondary, is plain bul****.
Having sufficient permissions(this is only secondary fact for you) I would just use Administrative Tools and never bother to deal with this Program.exe “exploit”.
Besides the executables search order is well documented in MSDN.
February 18th, 2007 at 2:05 pm
funny how these generic “windows is so unsecure” noob comments pop up in any discussion. “im gonna switch to a better os anyway”… lets see how half the companies relying on office and the embedded VBA tools switch to other oses. face it ppl, windows may be unsecure but its not replaceable, gates may be a dummfukk programmer, but hes a marketing genious, and thats what beats linux.
there is no discussion linux is the better os, but the point is, windows is so deeply routed into some work environments that changing to linux is not even near being an option.
@chris: yea true, but sadly the “documents and settings” folder containes spaces in virtually any localization.
as posted before often, make sure to give the right file system permission and you can harden windows systems pretty neat also. ofc no match for linux, but its a start
February 20th, 2007 at 5:01 am
Reed Arvin also covered this issue:
http://reedarvin.blogspot.com/2005/03/windows-privilege-escalation-using.html
As already mentioned, this goes back to the days of Windows NT… Really amazing.
March 1st, 2007 at 9:31 pm
[...] Keep in mind, however, that the local system might also log these if the local policy enables failed login auditing. If you know no one well ever check these logs you should probably be okay. If you have local admin access you can easily clear your own event logs. If you don’t have admin access on your own system, you have a bit more work to do to gain that. Perhaps you could try the program.exe trick. [...]
March 9th, 2007 at 6:07 pm
[...] Read more here: Windows Security News [...]