> From: Geoff Vass [mailto:geoff@xxxxxxxxxxxxx] > 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
