Home page logo

bugtraq logo Bugtraq mailing list archives

RE: Running renamed executables with CMD.EXE
From: Michael Wojcik <Michael.Wojcik () microfocus com>
Date: Tue, 24 Aug 2004 07:13:27 -0700

From: Geoff Vass [mailto:geoff () cadzow com au] 
Sent: Saturday, 21 August, 2004 07:43

[Your messages would be easier to read if you kept them to a reasonable line

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,

What's "fairly recently"?  If Symantec (not, IMO, the world's greatest
security products) is typical, then this hasn't been a problem for a while.
According to the Symantec KB, their anti-virus products since at least NAV
2000, except for NAV 2001, scan all files by default.[1]  And while NAV 5.0
scanned only "program files" by default, at least as far back as November
1999 Symantec had KB articles explaining (for the daft) how to configure it
to scan all files.[2]

and of course email 
attachment filtering
would not generally block a .txt file.

The only email attachment filtering that works worth a damn is common sense.
People who are "protected" from evil attachments by filtering will fall to
social engineering attacks such as phishing.

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).

MS products have been ignoring metadata for years.  It's well known that IE
attempts to determine disposition from content rather than from the HTTP

I suppose this makes it all the more ironic that MS is now pushing another
metadata "security" scheme, with the file zone ADS.  But really there's
nothing new here and nothing particularly exciting.

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 

This is only great insofar as you're dealing with an incompetent
administrator; under that assumption, there are plenty of other

To put it in more formal terms, you're worrying about pruning a rather small
branch of the attack tree.  There just aren't going to be many (if any)
attacks which depend solely on the capability of cmd.exe to process files
based on content inspection.

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.

No, that's not the first thing I do.  Perhaps your procedures need an

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.

Simply not true; IE is the most prominent example, but it's not the only

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.

Not a big deal, since the file zone ADS isn't worth the bytes used to store

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.

If interpositioning is an "obscure" attack, then I think cmd's behavior is
not your greatest worry.  Interpositioning should be completely obvious to
anyone with any degree of security training and understanding of Windows;
and anyone without security training has already lost the fight by the point
where an attacker can create files on the target.

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

"Intuitive" is what the user expects - no more and no less.  File extensions
as metadata that determines disposition is not a universal mechanism among
OSes.  It might be "intuitive" to people who used MS-DOS and older versions
of Windows, but it's not intuitive for Unix users, for example, and there's
no reason it should be for people who start with XP.  (And it doesn't even
translate to, say, people using MVS via TSO and ISPF, where you might exec a
CLIST or submit JCL, but you don't go creating programs that look like OS
commands.)  Ditto "obscure".

I'm not saying that cmd's content-inspection execution heuristics are good,
mind you; in fact I think that's a fairly stupid idea, particularly when
carried to excess, as it has been.  I think the Unix model (where only a few
magic numbers are recognized, and the rules are well-known) is a decent
compromise, and the old MS-DOS model (where there are strict execution rules
based solely on filename metadata, ie extensions) was clumsy but workable.
But I don't believe it's a huge threat; I think a formal model (such as a
well-drawn attack tree based on a reasonable threat model) would show you
that it's not; and I don't think "fixing" it is the right way to go, since
there's little to gain and potential compatibility issues.



Michael Wojcik
Principal Software Systems Developer, Micro Focus

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]