5

I finally gave in and decided to update XP to SP3. One of the things that bothers me about SP2+ and which caused me to put it off for so long is that it requires fully-qualified paths for file-types and Explorer verbs.

For example, in SP1, you could do something like the following:

REGEDIT4

[HKCR\txtfile\shell]
"@"="Notepad2"

[HKCR\txtfile\shell\Notepad2]
"@"="notepad2.exe %1"

Assuming that notepad2.exe is in the path, then you could open a text file by either running it directly or by selecting Notepad2 from its context-menu.

In SP2+, this will not work and displays the Open With… dialog instead. To fix it, you must use a fully-qualified path to the executable:

[HKCR\txtfile\shell\Notepad2]
"@"="e:\tools\editors\text\notepad2\notepad2.exe %1"

This change (which renders the PATH variable essentially pointless) was a security enhancement added to SP2’s Great Security Update, and it makes sense in that it prevents path-injection attacks.

However it is more trouble than it is worth because if a virus can modify your system path variable, then it’s already gotten access to the system and can do whatever it wants. Moreover, it only affects Explorer; running things from the command-prompt still works as before. In addition, it only works for the primary command; that is, the following still works if infectednotepad.exe is in the path:

"@"="e:\tools\misc\shellexecute.exe /c infectednotepad.exe %1"

This change doesn’t really provide any extra security; instead, all it does is to cause the user to have to spend hours scanning through the registry in each of the 6-10 different places where file-types, applications, and Explorer verbs can be registered, searching for unqualified paths and replacing each and every one (replacing only the main entry in HKCR is not sufficient because there are levels in other locations that compound and confound the problem).

In addition, Microsoft obviously realize that his “feature” was pointless because they removed it in Vista. In Windows 7, the first example works just like in SP1.

“Fixing” the items can be an insurmountable task for a system that has already been configured and used for any length of time, especially if third-party programs have been added.

Is there a way to turn this “feature” off and let the PATH variable do its job again?

7
  • No, there is no way to turn off this security fix. Seriously, if you have apps that didn't use fully qualified paths for their explorer verbs then they deserve to be broken by this change. Commented Feb 4, 2013 at 17:56
  • @Petesh, first of all, who said anything about apps? I have created registry patches of my own so that I can open different files and perform different tasks. Using FQPs is not always feasible because the location may change. You may like dumping everything in C:\Program Files, but not everybody does. Using the PATH makes sense because that is what it’s there for. Second, obviously Microsoft themselves realized this “security feature” was pointless because they removed it from Vista+; e.g., in Windows 7, like in SP1, the first one works ("@"="blah.exe"1, if blah.exe is in the path.
    – Synetech
    Commented Feb 4, 2013 at 18:07
  • if a virus can modify your system path variable: ...and your user path variable? Also, what about using the App Paths Reg Key?
    – afrazier
    Commented Feb 4, 2013 at 18:08
  • @Petesh, besides, many of the security patches in SP2 were to help novice users who don’t know a an infected file from their butts avoid getting in trouble. For those of us who know a little something about computers, most of these enhancements have been nothing but annoying headaches instead of helpful.
    – Synetech
    Commented Feb 4, 2013 at 18:09
  • if a virus can modify your system path variable: , @afrazier, obviously if it can modify the high-privilege system PATH variable, then it can modify the user one as well. I haven’t tried the App Paths; it might just do the trick. I’ll test it out the next time I’m in XP. (It is really annoying that there are a dozen or so places where things like this can be located.)
    – Synetech
    Commented Feb 4, 2013 at 18:12

1 Answer 1

0
  1. Boot into Safe mode.

  2. Export entire registry.

  3. Shutdown PC.

  4. On another box, write regular expression or simple script to scan for tokens and insert FQPs.

  5. Boot in safe mode again, import modified registry hive.

  6. Cross fingers and reboot.

2
  • Can you expand step 4, or at least share the magic incantation that makes it happen?
    – fixer1234
    Commented Oct 3, 2015 at 3:52
  • Hmmm. @fixer1234: I reread the question, and I think my answer may have been a little hasty. A regular expression would certainly be a simple solution, if all paths were the same - an unlikely case. What would be more suitable would be a script that would iterate over each path-less entry, supply the first location found via $PATH, possibly failing over to a full-disk index of all executables. I could probably provide reasonable answers for either case, but they'd admittedly use UNIX/Linux commandline tools.
    – i336_
    Commented Oct 11, 2015 at 10:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .