Likes: 
A while ago I "discovered" that CMD.EXE would launch renamed executables. I
felt that this was a security problem because until fairly recently most
virus scanners would be checking .exe, .com, .pif etc for viruses but would
not bother scanning .txt files, and of course email attachment filtering
would not generally block a .txt file. So I had an email conversation with
the fellas at secure@microsoft.com and they felt it was not a problem and
would not be changing the behaviour.
Coincidentally, shortly after MS issued KB811528 which says that CMD.EXE
looks at the header of the file and because it is an executable, executes it
and that you should only run code from trusted sources (blah blah blah).
I still think they focused too much on the fact that to demonstrate the
issue is basically a user-initiated client-side process, ie, you go to the
command prompt and type "malcode.txt" and malcode will run. And so
everybody thinks a user that does this is an idiot.
But the real issue to my mind is that if you are a hacker and you have
infiltrated a system a great way to hide your malcode would be to rename it
all to .txt or .tmp and launch it when required using "cmd /c malcode.tmp".
Of course you can say, the system has already been compromised and the
hacker could have simply used .exe files. But if you have ever tried to
clean an infected system or look for a possible compromise you know the
first thing you are looking for is funny .exe files. If the files have been
"hidden" by renaming them it is so much harder.
Consider also that tools such as Sysinternals' Autoruns, which now has a
function to show code not signed by Microsoft, would skip over an autorun
entry starting with cmd.exe because cmd.exe is a legitimate part of Windows.
I think it's a problem because we have a section of the operating system
that behaves totally counter-intuitively, considering that every other part
of the operating system looks at the file extension and not the contents. If
you rename an .exe to .txt and double-click, Notepad opens. Yet CMD.EXE
executes it. And now we have this new functionality in the shell which
remembers which zone a file was downloaded from and prompts you according to
its safety level yet CMD.EXE totally ignores it. And this from a company
that went so far as to alter the DLL search order behaviour to block certain
types of DLL spoofing, which is another obscure type of attack that assumes
the malcode is already in your system.
So considering all the tweaking that took place in Windows XP for SP2 it's a
bit peculiar that this obscure and counter-intuitive behaviour has remained
intact.
OK, sure, it's not a vulnerability. It's completely useless until the
malcode gets into your system and the breathless media attention to this
issue has been ill-informed and panicky. But to a hacker it's a useful bit
of misbehaviour that can be handy if you're trying to avoid detection. It
really ought to be "fixed".
Geoff Vass
Australia
Quote
