Scripting: Safe Command Line Conventions for Fun and Profit
Microsoft Windows contains many command-line utilities which are very useful for managing systems. Some commands are built into the command processor (cmd.exe) such as dir, while others are standalone executables from the System32 folder, such as find.exe.
The Windows command processor inherits very old behaviour from the MS-DOS command processor when it deals with launching programs. When a command is typed, say:
the command processor looks for all files called ipconfig.* in the current folder. If nothing is found, it then parses the list of folders in the PATH variable, and looks for the files in each folder in turn. (To see the value of PATH, open a command prompt and type SET PATH.)
If the command processor finds matching files, it will execute them in the order defined by the extensions list in the PATHEXT variable, which by default looks like:
Therefore, if a file called ipconfig.com or ipconfig.cmd (say) is found in the current folder, or a folder in the PATH variable, that's what will be executed.
This is undesirable because it is very likely that if ipconfig is being requested, the intention is not to run something called ipconfig.com or ipconfig.exe from some other location. The point is that if an attacker has somehow left an executable on the system with an identical name to a common Windows utility, a script may execute that file instead of the genuine one.
Scripting is used to batch commands together for repeated use, to save time on repetitive tasks, and often those scripts are used across many systems. So it's not possible to know ahead of time whether a given system is clean, or has a lot of illegitimate files on it.
So while using ipconfig in a script is convenient, and lets the command processor do the work of finding the file, it's much safer and slightly quicker to reference the file as %SystemRoot%\System32\ipconfig.exe. This notation guarantees the file being used is the genuine version from Windows.
Certainly, the risk of inadvertently running a malicious file with the same name as a Windows utility is low. But in a scripting environment, the additional effort in using fully-qualified path/filenames for utilities is small and reduces the malware risk from low to zero.