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 companion virus. Show all posts
Showing posts with label companion virus. Show all posts
Thursday, August 26, 2010
Wednesday, September 20, 2006
symantec and the poor man's 'rootkit'
can't we stop calling everything a rootkit? please?
i grow weary of pointing out terminology misuse over and over again - from stealth digital rights malware, to protected recycle bins, to anti-virus products, to alternate data streams (yes, ADS all by itself has been likened to a 'rootkit') - but if someone sinks to a new low, well the full range of this terminology abuse needs to be documented in order to underscore how idiotic it is...
the latest 'new low' comes from symantec where the 'rootkit' label is being (loosely) applied to a trojan that scans through the registry for programs that get run and then replaces one (or more?) of them with a copy of itself while saving a backup of the original to execute after the trojan gets executed...
so apparently now trojans that employ the non-viral equivalent of companion file infection are 'rootkits'... well gee, at that rate just about any kind of program paracitism (i hesitate to call it file infection as i reserve infection for self-replicators) is a 'rootkit' technique since just about all of them hide changes as well as or even better than companion infectors (overwriting infectors are about the only kind that does a worse job)... so nearly all file infecting viruses and other forms of paracitic malware are 'rootkits' - yeah, that's a wonderful message to be sending people who look to you for expert analysis, symantec... thanks a lot...
things weren't bad enough when virus was treated as an umbrella term, or when spyware became the new umbrella term, now it's going to be 'rootkit'... let's take this absurd "if it hides things it's a rootkit" business to it's logical conclusion, shall we? file permissions are a 'rootkit' technique, attrib is a 'rootkit', popups are 'rootkits', the cursor is a micro-'rootkit' - my trousers are a 'rootkit'...
i grow weary of pointing out terminology misuse over and over again - from stealth digital rights malware, to protected recycle bins, to anti-virus products, to alternate data streams (yes, ADS all by itself has been likened to a 'rootkit') - but if someone sinks to a new low, well the full range of this terminology abuse needs to be documented in order to underscore how idiotic it is...
the latest 'new low' comes from symantec where the 'rootkit' label is being (loosely) applied to a trojan that scans through the registry for programs that get run and then replaces one (or more?) of them with a copy of itself while saving a backup of the original to execute after the trojan gets executed...
so apparently now trojans that employ the non-viral equivalent of companion file infection are 'rootkits'... well gee, at that rate just about any kind of program paracitism (i hesitate to call it file infection as i reserve infection for self-replicators) is a 'rootkit' technique since just about all of them hide changes as well as or even better than companion infectors (overwriting infectors are about the only kind that does a worse job)... so nearly all file infecting viruses and other forms of paracitic malware are 'rootkits' - yeah, that's a wonderful message to be sending people who look to you for expert analysis, symantec... thanks a lot...
things weren't bad enough when virus was treated as an umbrella term, or when spyware became the new umbrella term, now it's going to be 'rootkit'... let's take this absurd "if it hides things it's a rootkit" business to it's logical conclusion, shall we? file permissions are a 'rootkit' technique, attrib is a 'rootkit', popups are 'rootkits', the cursor is a micro-'rootkit' - my trousers are a 'rootkit'...
Tuesday, June 06, 2006
what is a companion virus?
a companion virus is a virus that exists as a separate (companion) program to the host program...
it may not be obvious how something like this would be able to meet the definine criteria of a virus and may sound more like a worm, however a companion virus is able to infect host programs without modifying their contents (that is how they can be separate programs)... it does this by taking advantage of operating system features that allow it to be executed instead of it's host program...
for example - in DOS if you type a program name without specifying the path and that program happens to not be in the current directory, DOS will search each directory in your PATH sequentially until it finds a program with that name or it reaches the end of your PATH... a path companion virus need only assume the same name as an existing program on your computer but place itself in a directory closer to the beginning of your PATH so that DOS finds the viral program first and executes it instead of the program the user intended...
another type of companion infection utilizes the fact that if a program name is specified without a file extension, DOS will look for *.com files before it looks for *.exe files so the virus need only copy itself as ProgramName.com in the same directory as the original ProgramName.exe in order to get executed...
some flavours of *nix (as well as some alternative DOS shells) have a command alias facility that can also be used for companion infection...
additionally, a virus could rename or make a backup copy of the host program and then replace the original with itself and be yet another kind of companion virus...
the original program is generally retained so that the companion virus can execute it after the virus itself gets executed - this makes the system appear to behave properly since the program you intended to execute does get executed....
back to index
it may not be obvious how something like this would be able to meet the definine criteria of a virus and may sound more like a worm, however a companion virus is able to infect host programs without modifying their contents (that is how they can be separate programs)... it does this by taking advantage of operating system features that allow it to be executed instead of it's host program...
for example - in DOS if you type a program name without specifying the path and that program happens to not be in the current directory, DOS will search each directory in your PATH sequentially until it finds a program with that name or it reaches the end of your PATH... a path companion virus need only assume the same name as an existing program on your computer but place itself in a directory closer to the beginning of your PATH so that DOS finds the viral program first and executes it instead of the program the user intended...
another type of companion infection utilizes the fact that if a program name is specified without a file extension, DOS will look for *.com files before it looks for *.exe files so the virus need only copy itself as ProgramName.com in the same directory as the original ProgramName.exe in order to get executed...
some flavours of *nix (as well as some alternative DOS shells) have a command alias facility that can also be used for companion infection...
additionally, a virus could rename or make a backup copy of the host program and then replace the original with itself and be yet another kind of companion virus...
the original program is generally retained so that the companion virus can execute it after the virus itself gets executed - this makes the system appear to behave properly since the program you intended to execute does get executed....
back to index
Subscribe to:
Posts (Atom)