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.
--
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D
Attachment:
pgpUEaBJ5H5hE.pgp
Description: PGP signature