Just my $0.02 on the topic, but there are multiple kinds of "remote exploits" There's remote-active, where the exploit is carried out against a system actively (either manually or via an automated process), such as your example for BIND and various worms vs Windows (CodeRed, Nimda, MSBlast, etc). There's remote-accessible, where the exploit isn't activated directly from remote, but is still manipulated via remote, such as your EMail trojan example. If I couldn't get the code from remote on to the system, there would be no exploit. The initial "remote-active" exploit in this case would be the social engineering aspect of getting the user to open the email I sent. Then you get into "local exploits" which require direct (and sometimes physical) access to the device in question. Could I have walked up and downloaded the trojan in question and manually executed it? Sure. Anything in the 'remote-accessible' region would be repeatable as a local exploit while not everything in 'remote-active' could be. The answer ultimately is: There's a LOT of gray out here... Exploits are exploits. They're generally all bad and need to be handled properly when encountered. Derek Martin wrote: >The issue has come up on bugtraq before, but I think it is worth >raising it again. The question is how to classify attacks against >users' client programs which come from the Internet, e.g. an e-mail >carrying a malicious trojan horse payload. The reason this is >important is because we judge how serious a particular vulnerability >is based on how it is classified. We normally ask two main questions: > > - Is this a root vulnerability, i.e. does it have the potential > grant the attacker the privileges of the system management account? > > - Is the vulnerability remotely exploitable? > >The latter is a question which, when an answer is attempted, >sometimes raises debate. The case of the trojan e-mail is a prime >example of this. > >Some are tempted to call this a remote exploit. The payload finds its >way to the attacker's machine via a network, after all... The >attacker isn't logged in to the victim's machine. Security >researchers are also eager to publish remotely exploitable >vulnerabilities, perhaps because such a vulnerability is generally >considered to be much more severe than one that is not, and thus more >notariety comes with publishing such a vulnerability. > >This kind of attack has a name already: it is a trojan horse. A >malicious payload is disguised as an innocuous e-mail, usually with an >attachment. Once the user views the e-mail, or possibly even when the >mail client tries to display headers in the message index, a bug is >triggered which unleashes the payload on the poor unsuspecting user. >But is this a remote exploit? > >Examine what is happening when the exploit is executing. The payload >is already on the user's system. It was delivered via some MTA >(possibly the same program the user uses to read mail, possibly not) >onto the user's filesystem. This is the remote part. But, usually, >at this point there has been no exploit. Only after the user opens >the mail, or looks at it in the message index, does the exploit >happen. The payload is already local to the machine, and it is the >action of a local user which triggers the exploit. It is a passive >attack, launched by an attacker who can only HOPE that the user will >fall into his trap, even if he knows the user is using vulnerable code. >Nothing the attacker can do remotely will force the exploit to be >triggered. Only once the user has acted will the payload become an >exploit. This is not truly a remote exploit. > >By contrast, look at a remote exploit against BIND. An attacker >launches the attack, which is an active attack... The attacker sends >data directly to the running named daemon, in order to exploit some >bug in the program. The actions of the attacker, if he is successful, >are the direct cause of the compromise. Once the DNS server software >has been started, no intervention is required by a user on the local >system to effect the exploit. This is a true remote exploit. > >What is clear is that e-mail trojans, and other kinds of attacks which >are similar in nature, ARE more of a threat than what we normally >think of as local exploits, and should be treated as such. They have >some similar characteristics to remotely exploitable vulnerabilities: >they can allow an attacker who normally would not have authorized >access, or even physical access, to gain access to the system. But >they are not as severe as truly remote exploits, because often (if not >most of the time) careful users can avoid the affects of such an >attack, even though they may be running vulnerable code. > >So let's return to the questions we ask, when deciding how severe an >attack may be. Perhaps what we need is not to call these remote >exploits, but to ask a new question: Does the vulnerability make my >system susceptible to trojan horse attacks? These vulnerabilities >really should answer "no" to the remote exploit question, but "yes" to >this new question. A yes answer here clearly indicates a more severe >threat than a local exploit, but somewhat less of a threat than a >truly remote exploit. Assessing the threat properly helps everyone. > > >