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).
Showing posts with label execution precedence companion virus. Show all posts
Showing posts with label execution precedence companion virus. Show all posts
Thursday, August 26, 2010
what is an execution precedence companion virus?
an execution precedence companion virus is a type of companion virus that takes advantage of the precedence or order in which DOS tried to find a partially specified executable file when attempting to execute it.
the canonical example is one where a DOS command is issued that would normally execute a file with an *.EXE file extension - should there be a file with the same name but a *.COM extension in the same directory, the *.COM file will be executed instead. in order to hide the fact that there was something unusual going on, the *.COM file would generally then explicitly execute the *.EXE file so that the program the user intended to execute actually gets executed.
whenever there are multiple executables with the same name but different file extension in the same directory, the system will always use a set rule to decide which takes precedence over the others. *.COM files take precedence over *.EXE files, which in turn take precedence over *.BAT files, and so on...
back to index
the canonical example is one where a DOS command is issued that would normally execute a file with an *.EXE file extension - should there be a file with the same name but a *.COM extension in the same directory, the *.COM file will be executed instead. in order to hide the fact that there was something unusual going on, the *.COM file would generally then explicitly execute the *.EXE file so that the program the user intended to execute actually gets executed.
whenever there are multiple executables with the same name but different file extension in the same directory, the system will always use a set rule to decide which takes precedence over the others. *.COM files take precedence over *.EXE files, which in turn take precedence over *.BAT files, and so on...
back to index
Subscribe to:
Posts (Atom)