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
length.]
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
headers.
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
malcode.tmp".
This is only great insofar as you're dealing with an incompetent
administrator; under that assumption, there are plenty of other
opportunities.
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
update?
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
one.
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
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.
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
intact.
"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.
1.
http://service1.symantec.com/SUPPORT/nav.nsf/df0a595864594c86852567ac0063608
c/4978f97c99d2fa7b8825690d008012d6
2.
http://service1.symantec.com/SUPPORT/sunset3.nsf/4a466c543a83dec985256c92005
cb9ae/2154e3ea5303ddbf85256c92005b5ce9
--
Michael Wojcik
Principal Software Systems Developer, Micro Focus
-----
NTBugtraq Editor's Note:
Want to reply to the person who sent this message? This list is configured such
that just hitting reply is going to result in the message coming to the list,
not to the individual who sent the message. This was done to help reduce the
number of Out of Office messages posters received. So if you want to send a
reply just to the poster, you'll have to copy their email address out of the
message and place it in your TO: field.
-----
