are companion infectors contrived?

while reading a recent threatpost article i was rather taken aback by the following quote:

However, one security researcher said that the vectors for using EXE files in this kind of attack are unlikely to be seen in the real world. HD Moore, CSO of Rapid7 and founder of the Metasploit Project, said that he'd seen some cases of other file types being vulnerable to this kind of attack, but didn't think widespread exploitation was likely.

"Most of the EXE cases are contrived vectors, not realistic for exploits," he said.

i suppose path precedence companion viruses must be contrived then. but if that's so then mr. moore must be using a meaning of contrived that i'm not familiar with, because not only did they work reasonably well in their day, but they still operate quite well even now.

to be clear, and to avoid hyping the issue, i should point out that they aren't much of an issue for users of windows explorer. the way explorer works and the way it's used doesn't necessarily lend itself to this attack. but if you use the command line or happen to write and/or use scripts then planting *.EXE binaries can most definitely still pose a security problem - and there are still users in that group, many of them IT or infosec professionals. i would hope that such people would have an awareness of such a threat, but i've seen increasing evidence that people (even security folks) just don't get viruses in general (even after over 1/4 of a century) much less an obscure, ancient kind like this.

the problem with DLL search paths

recently, some old news has become new again. when i first read about DLL search order hijacking in nick harbour's post on mandiant's blog i thought to myself 'gee, that sounds an awful lot like a companion virus, except without the self-replication part'.

apparently i wasn't the only one. robert sandilands made the companion virus connection too, except for some reason he combined execution precedence companion viruses with path precedence companion viruses. path precedence is the only one needed here, and if you really think about path precedence companions or you go back and read nick harbour's post again you'll see that the all this focus people are giving to the issue of the current directory is taking attention away from a broader issue.

while the current directory could be used to initiate a compromise of a machine, if the malicious DLL is anywhere in the search path before the legitimate DLL there will still be a problem with an exotic form of persistence, and if an additional vulnerability (say in a browser, for example) can be used to plant a malicious DLL at the beginning of the search path then we will once again be able to compromise a machine regardless of the current directory centric mitigations that are available right now.

the real problem with DLL search paths is that they exist at all. there should be no searching, no question of which DLL your process is trying to load or where to find it. so long as there is searching for DLLs, there exists the possibility of finding and loading the wrong one (the malicious one).

what is a path precedence companion virus?

a path precedence companion virus is a type of companion virus that takes advantage of the precedence or order in which DOS traverses the PATH variable (a delimited list of directories) to find a partially specified executable file when attempting to execute it.

as a simple example, suppose the PATH variable holds just two directory names. if we issue a command to execute a file that happens to be in the second directory but we don't specify which directory it's in, DOS will search the first directory and then the second directory in order to find and execute the file. if another executable with the same name as our intended command happens to exist in the first directory then it will get executed instead of the one we intended.

regardless of where the program we intend to run is, if a companion program exists in a directory closer to the beginning of the PATH, that program will get executed instead.

back to index