Program names in file type handlers need to be fully-qualified


Most people probably haven't noticed this, but there was a change to the requirements for file type handlers that arrived with Windows XP SP 2: Paths to programs now must be fully-qualified if they reside in a directory outside of the Windows directory and the System directory.

The reason for this is security with a touch of predictability thrown in.

Security, because one of the places that the SearchPath function searches is the current directory, and it searches the current directory before searching standard system directories or the PATH. This means that somebody can attack you by creating a file like say "Super secret information.txt" and creating a hidden NOTEPAD.EXE file in the same directory. The victim says, "Oh wow, look, super secret information, let me see what it is," and when they double-click it, the trojan NOTEPAD.EXE is run instead of the one in the Windows directory. Requiring paths to be fully-qualified removes the current directory attack.

Predictability, because the contents of the PATH environment variable can vary from process to process. Consequently, the relative path could resolve to different programs depending on who is asking. This in turn results in having to troubleshoot problems like "It works when I double-click it from Explorer, but not if I run it from a batch file."

Comments (29)
  1. DavidE says:

    This is something we had to deal with in the Unix world decades ago. Many people would stick "." in their path before system paths, and it was quite common for people to write shell scripts called "test". Shell scripts that used the test command (used for checking for files and comparing numbers and strings) would sometimes inexplicably stop working. Of course, the real fix was to specify the path in the shell script…

  2. endothermal says:

    Good thing, but one of the biggest security problems still exists to this day and still exists in longhorn. Hiding the extension of known files types is a major security risk and wtf all roled up in one. Don’t think it’s a security risk? Readme.exe and Readme.txt can be made to show up with the same icon, so with the extensions hidden which one should I click on? This "feature" should be turned off, all extensions should be visible all of the time, if someone wants to play with fire and turn off the visiblity of extensions let them but put a warning.

  3. denis says:

    True, hiding extensions is always the first thing I disable in Explorer anywhere.

    I also mostly use the Command Prompt instead.

  4. Dave Solimini says:

    Endothermal has a point — i’ve seen a number of trojans that create things like "ipconfig.com" in the windows folder which are trojan servers… they run before ipconfig.exe, of course, meaning that when you try to get rid of the bug by running IPCONFIG, or NETSTAT (another example) to see what it’s up to, you end up re-running the trojan server!

  5. Steve says:

    Dave, that just goes to show that a system which has been compromised can never be trusted again. We’ve been dealing with that in the Unix world for a long time too, and the standard advice applies to Windows too. Once a system is compromised, the only safe course is to format the disks, reinstall from known good media, and restore user data from backups.

  6. Robert says:

    Although I strongly agree that the hidden file extensions should be turned off by default (any maybe even remove the option all-together), another option would be to force an icon overlay on any executable when the extensions are hidden. That way it would be more difficult to visually trick the users into clicking on ‘MyHarmlessTextFile.exe’

  7. Matt says:

    Robert, this is what GNOME does, isn’t it? It’s been a while, so I can’t remember for sure.

  8. Robert says:

    It very well may be. Unfortunately I havn’t had the privelidge of running GNOME yet – I have always used KDE.

  9. Mike says:

    All those hardcoded paths in the Registry always bugged me. What if you want to move a program because a drive is full or whatever. Impossible.

    Yuck.

  10. endothermal says:

    hard coding paths in the registry is the developers choice, not a requirement of using the registry. Relative paths can be used quite easily and for the most part paths in the registry aren’t necessary.

  11. foxyshadis says:

    All I feel on the extensions issue is that it’d be great if they didn’t show in thumbnail mode because they make changing the name rather more inconvenient. Otherwise I don’t mind them off or on.

    It’d be nice if longhorn would disable extension hiding for executables and scripts entirely. The chance that J. Random User is going to care about seeing setup.exe.vbs or ipconfig.com is pretty low even after years of virus warnings, but it’d raise red flags in more experienced users. Icon overlay, full extensions, something like that.

    On the other hand all a trojan/user has to do is associate another extension with a scripting engine; checking on every folder access would be slow and almost pointless.

  12. Jack Mathews says:

    >> hard coding paths in the registry is the developers choice, not a requirement of using the registry. Relative paths can be used quite easily and for the most part paths in the registry aren’t necessary. <<<

    Unless you want to use implement an OLE object. Or bind your application to opening files from the shell. Or allow your program to be removed from Add/Remove. Or allow your EXE to start up by just typing it in the Run box without a path. Or if you’re a shell extension (which actually falls into OLE above).

  13. josh says:

    "All those hardcoded paths in the Registry always bugged me."

    Um… if it’s in the registry, it’s not hard coded.

    Anyway, how else do you propose for program A to find program B without a path stored someplace? What if you need to move program B to a different drive because the one A is on is full?

  14. AC says:

    josh: "Anyway, how else do you propose for program A to find program B without a path stored someplace?"

    Find some old Mac, with 15 years old OS, and try to move the whole System folder (that’s equivalent of C:windows) somewhere — and everything will work. Then move any application anywhere — and everything will still work.

    Hint 1: Already on these old Macs one application would contain everything needed in one single file (only MSFT applications didn’t quite follow this practice :) ). Imagine all DLLs etc. of one application all in the one file, like when you’d on Windows be able to have one ZIP with EXE and all DLLs, which would run when you click on it.

    Hint 2: The file system was able to find the application only by name fast enough (like Google now can find something only by name).

  15. Darius says:

    "Good thing, but one of the biggest security problems still exists to this day and still exists in longhorn. Hiding the extension of known files types is a major security risk and wtf all roled up in one. Don’t think it’s a security risk? Readme.exe and Readme.txt can be made to show up with the same icon, so with the extensions hidden which one should I click on?"

    I think most of us would rather have the convenience of an easy to read display than worry about such a incredibly rare risk scenario.

    You make it sound like anyone can drop any file they like on to your computer at any time, in which case you have bigger problems.

    It could be a good precaution for inexperienced users, but such users will probably ignore the extension even if they can see it.

    As for the rest of us, we usually know what we are clicking on and whether it should be there or not. I am not sure why it is ‘WTF’ – human reading of file extensions has been replaced in the modern world with icons which do the job just fine. Of course, I know developers who think all files must be 8.3 and that non-abbrieviated names are evil, but it takes all sorts.

  16. zzz says:

    When Microsoft stops using 8.3 and file extensions under all files they have under WINDOWS then I’m inclined to say it’s time to move on (from the visible extensions). And by that time the other issues around this have been solved…

    How? There could be something like LEGCYCRP.IMG with all the 8.3 and other legacy stuff. Apps requesting data through obsolete APIs will look for the files under that image.

    The pre-requisite for this is to have Windows finally support reading and mounting images natively. Too late for Vista? Thought so.

  17. Cheong says:

    Talking about compromised system, we have a client who has a "almighty" server being compromised a few days ago. They really couldn’t be blamed because they have firewall(hardware+software) and antivirus running, and they use SUS to deploy patches promptly. Just that the XXX antivirus doesn’t protect them.

    We talk to them about format and rebuild the server, but since it’s "almighty", AD, exchange, SQL, FTP, Web… everything runs on it and they can’t afford to take it down. So we end it searching it fullday by software and by hand for any "The Bad Things(TM)". And we’ve told them we have no confidence to remove everything that might have been done to the server.

    Any better advice?

  18. Ben Hutchings says:

    foxyshadis wrote: "All I feel on the extensions issue is that it’d be great if they didn’t show in thumbnail mode because they make changing the name rather more inconvenient. Otherwise I don’t mind them off or on."

    They don’t have to make changing the name more inconvenient. For example, Nautilus (the GNOME equivalent of Windows Explorer) shows extensions, but if you rename a file that has an extension only the main part of the name is initially selected.

  19. Curiously, more often than not, if I rename a file it’s because I want to change the extension. Speaking of txt to xml/xsl/bat/cmd , or zip to jar/mzp. And this is not possible with extension hidden.

    BTW is there some way to disable the "you are renaming the extension" boring dialog ?

  20. AndyB says:

    WRT the ‘almighty’ server, you’ve just discovered the need for grandfather, father son backups.

    As long as you spot the compromise before the grandfather backup is recycled, you can restore from that at the worst. Hopefully that will be a lot better than reinstalling everything.

  21. Ytram says:

    "BTW is there some way to disable the "you are renaming the extension" boring dialog ?"

    Seriously. Are there actually any files any more that will be corrupted by changing their extension?

  22. Tim Smith says:

    Ytran – "Seriously. Are there actually any files any more that will be corrupted by changing their extension?"

    You are thinking from a programmer’s viewpoint and not a user’s viewpoint. If I rename a file from .doc to .txt and then double click, I get a bunch of trash in Notepad. The file seems to be trashed. It is true that all I have to do is change the extension back, but many users don’t know this. They spend a bit of time trying to figure out what is going on first. During that time, they have tried to delete a bunch of those funny characters in order to get to their text they can see. (i.e. "Dear Mom,"). When someone who knows what is going on gets back to the computer and tries to rename the file back, it has been trashed by being saved from the wrong editor.

    Silly? That can’t ever happen?

    It happens. More than you think.

  23. >It happens. More than you think.

    Yes but the fact that a feature (the alert messagebox) is useful to many non power users, a workaround to disable that feature should be available for power users. A problem I constantly have with Windows (and Office btw) is that behaviours intended to protect unsavvy users end up creating useless burden on "power users". I think of things like renaming an extension, of outlook blocking "unsafe attchments" (whose workaround is either zipping the file or renaming the extension..).

  24. Centaur says:

    and creating a hidden NOTEPAD.EXE file in the same directory

    Oh yes. Hidden files.

    A friend asked me yesterday, “My antivirus says I’ve got Bloodhound.Morphine and it cannot cure the infected file, what’d you advise?”

    Of course the first thing I do, I switch to my browser and say “gg Bloodhound.Morphine”. The topmost link tells me exactly which antivirus that was and that it can’t possibly do anything useful because it doesn’t know what virus it is.

    So I suggest her to upload that file to any of the online virus checking services, such as http://www.kaspersky.com/scanforvirus or http://www.drweb.com/online/ . She thanks me but says the Browse dialog does not display that file.

    What do you mean it does not display that file, I say. Where does the Symantec antivirus say the file resides?

    C:WINNTsystem32wininit32.exe, she says.

    Now, the user has a problem. There is a malicious file in the system directory but the system protects the user by sticking her head into sand. And if a more technically savvy user were to pull her head from the sand and manage to see the file, she would not be able to remove the file, thanks to the Windows System File Protection. If it is in the system directory, surely the user has no business deleting it?

    So the user has a problem. And if the user has a problem, the company has a problem.

    Of course the problem could be prevented. Modern systems prevent this by not trusting ordinary users and removing write access rights from them. DOS prevented this by trusting the user and requiring him to educate himself. Windows, at least up to and including XP, trusts the user (by making the first user created on the system a member of Administrators) but does not promote education by discovery (These are protected operating system files! They’re too difficult for you to understand! Although it is precisely this listing of legitimate system files that the user needs to know in order to recognize a malicious system-file-wannabe.)

    So the company has a problem. The time has come to make a choice. Either an ordinary user is not worth the system’s trust and should have no write access to %SystemRoot% and %ProgramFiles% and whatever directories he can create automatically have execute access disabled with no way to enable it except asking the administrator, or the user must be shown everything and told why it works. The former will learn only the minimum necessary for his work, but will not be able to do anything harmful. The latter user will foul up his system beyond repair a couple of times, but will grow up to be a power user.

  25. Bryan says:

    > I think most of us would rather have the

    > convenience of an easy to read display than

    > worry about such a incredibly rare risk

    > scenario.

    "Incredibly rare"? Do you have any idea how many double-extension attachments are floating around? Any of which, if the email reader is configured the same way as the OS (or the file is saved to the hard drive), will *BE* this risk scenario.

    (IMO, the real problem is that the "file type" metadata is encoded in the filename. PE files and MS-DOS executables both have specific file formats and magic numbers; why not use those to decide which files are executable? Many script languages have specific magic numbers in certain places (#! as the first 2 bytes for anything from Unix; not sure on VBS though), so that might be an option too.)

  26. Brian says:

    So, I’m curious as well. Is there any documented way of turning off the extention-rename-confirm dialog? I suspect that answer is no since I’ve certainly never seen such a thing in any settings dialog or any registry entry. Maybe a shell extension could do it?

  27. foxyshadis says:

    I feel bad that I just found AlwaysShowExt in the registry, basically invalidating half my rant. Sigh. It’d still be nice to put them on .exe/.vbs/.js by default, but I least I can do it myself and have a policy do it.

    Centaur: SFP only protects files that are listed in the system file catalog, though of course a virus could get itself in there. But most users do not ever become power users, no matter how many problems they come across; anyone geek enough to ever become one would click the option to view the files. Torture training a few people to become self-sufficient while allowing everyone to blow up their machines regularly certainly isn’t in any company’s interest.

  28. Aren’t these comments about the value of showing the file extension somewhat random?

    You have the same issue with display of text that you do with display of icons. We’re not 7-bit clean any more.

    This is a real issue, but showing the full extension is something we geeks like, not an actual security measure.

  29. David Walker says:

    Darius: You said "human reading of file extensions has been replaced in the modern world with icons which do the job just fine."

    I’m a human, and I read the extensions. I see the icons too, but I rely on the extensions even more. Icons can be changed, but when extensions are changed, the action (generally) changes.

    Please don’t attempt to speak for everyone.

Comments are closed.