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?
C:\Program Files
, but not everybody does. Using thePATH
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
, ifblah.exe
is in the path.if a virus can modify your system path variable
: ...and your user path variable? Also, what about using the App Paths Reg Key?if a virus can modify your system path variable:
, @afrazier, obviously if it can modify the high-privilege systemPATH
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.)