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 LT 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. 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. 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 HPE 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. 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. 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.
>

PGP SIGNED MESSAGE
Hash: SHA1

Jul 14, 2005, at 9:39 PM, Derek Martin wrote:

This kind of attack has a name already: it is a trojan horse.
<snip>
But is this a remote exploit?

No, it's not an exploit at all. Systems are not vulnerable to it
unless a local user runs an executable. The only thing it exploits
is trust of email (or similar vector).

Your example involving BIND is a good example of a true remote
exploit. A local exploit is typically categorized as one that
requires permissions on the system to begin with, and is used to gain
elevated permissions (such as exploiting a setuid program, or causing
root to write files through symlink race conditions).

This leaves one significant class of vulnerabilities, however. Let's
imagine for a moment that there is a buffer overflow in libjpeg that
allows an attacker to create a malicious JPEG which can cause any
program using libjpeg to execute arbitrary code. This should be
classified as a remote vulnerability. Users should be able to trust
that opening a JPEG file will only cause certain code to run, namely
decoding and displaying that JPEG.

PGP SIGNATURE
Version: GnuPG v1.4.1 (Darwin)

xXQ3xMVvvTAZZtz7jXXd12o=
=EhoG
PGP SIGNATURE

PGP SIGNED MESSAGE
Hash: SHA1

Sat, 16 Jul 2005 12:40:29 -0400, Derek Martin <code (AT) pizzashack (DOT) orgwrote:

It seems to me your statement can't be correct, because this is ALWAYS
the case. A local exploit requires that a local user run an
executable. A remote exploit requires that a local user run an
executable, even if that is accomplished merely by booting the system.
All exploits require running code, and code doesn't magically start
itself Running code is required, because it is the very running
code which is being exploited.

Maybe so, however with the case of the BIND attack, the vulnerability in
locally running code (named) is being exploited by a remote attacker via the
network.

In the case of an e-mail containing malicious code, the code being exploited
(parts of the Windows kernel or whatever) is being attacked by code running
locally - on the *same* machine. In this sense it can hardly qualify as a
"remote" exploit.
- --
G. Stewart - gstewart (AT) spamcop (DOT) net

A lot of money is tainted. 'Taint yours and 'taint mine.
PGP SIGNATURE
Version: GnuPG v1.4.1 (GNU/Linux)

fEc+qbBBB4LKkzeR5bKMikg=
=yzAH
PGP SIGNATURE

Sat, 16 Jul 2005, Derek Martin wrote:

It seems to me your statement can't be correct, because this is ALWAYS
the case. A local exploit requires that a local user run an
executable. A remote exploit requires that a local user run an
executable, even if that is accomplished merely by booting the system.
All exploits require running code, and code doesn't magically start
itself Running code is required, because it is the very running
code which is being exploited.

Yes, but a trojan requires a user to run a program, not open a file.
JPEGs are an image format, not an executable format. one should
display the image, not run arbitrary code.

I think this is also not the case. To exploit essentially means to
use. These attacks USE the users' trust of e-mail in order to USE a
bug to gain access to USE the system for his own purposes That
certainly seems like an exploit to me.

But it's not a bug. A computer that runs an executable when it is
double-clicked does not have a vulnerability.

Example:

All Unix systems are "vulnerable" to loss of data through the following
exploit: an attacker sends the string "rm -rf /" through email. If the
system administrator gives this string to his shell running as root, all
data on the system will be lost.

We disagree here. The vulnerability is neither truly remote nor
local, in the normal senses as we have defined them here. It is a
different kind of vulnerability altogether. The vulnerability is one
to automatically triggering trojan horses Just as in the case of
the fabled Trojan Horse, there is no vulnerability at all until the
local users make a decision to trust something (data in this case,
rather than a hollowed out horse-shaped monument) from an outside
source. In this case, the trust is given implicitly rather than
explicitly. This is no different than if I handed you a disk, told
you to run the program on the disk, and you did so -- resulting in the
destruction of your hard drive. Would you call this a remote
vulnerability? course not. But the mechanism is exactly the
same except that some of the minor details are different.

It's completely different. If you gave me a program on a disk, I wouldn't
run it, because I know that programs that I run can do whatever they want
on my system. That's not because of a bug, it's because that's what a
computer does -- run programs.

The only difference is the medium used to deliver the trojan horse is
a network instead of a disk, and it is slightly more automated,
because you are prone to automatically view the data out of habit. If
I did hand you a disk and tell you to run the program on it, you would
probably be a lot more wary of doing so than you would of reading your
e-mail, wouldn't you? Especially if you don't know me very well. But
if you were dumb enough to do so, would you call this a remote
exploit? What if I gave you a disk that had an Excel spreadsheet on
it, which contained data designed to take over your system using a bug
in excel Is this a remote exploit? I don't think so. Now I use
the same excel spreadsheet, but I send it to you in e-mail instead of
giving it to you on a disk. In all cases, I have given the data to
you. In all cases, there is no exploit at all, until you, the local
user, decides to trust the data, and run broken code against it. The
only difference is the specific delivery mechanism, and the fact that
the average user implicitly trusts data received in e-mail. Because
really, what choice do they have?

If you gave me an Excel spreadsheet on disk, I would expect to be able to
open it and see a spreadsheet. I am allowing you to display a spreadsheet
on my system, not to run arbitrary code. If there was a bug in Excel, you
would be able to exploit my legitimate trust in Excel to run arbitrary
code.

If you gave me a program on disk and I ran it, I am giving you permission
to run arbitrary code on my system. Therefore, there is no bug. The
blame lies solely on me, not on my operating system, computer, or the
program itself.

But this is still not a remote vulnerability. It is a user trust
vulnerability, as you said yourself. And it is a vulnerability (or
susceptibility) to trojan horse data. The fact that the data just
happens to come in via a network is largely irrelevant. A remote user
can, IN N WAY, effect an exploit against this kind of vulnerability
merely by his own action. This exploit can not happen unless you, the
local user, do it for him. This is the essential reason why it is not
a remote vulnerability.

Yes, but opening an untrusted image file, for example, is a legitimate use
case. I would assume that almost all of us do so multiple times a day.
Trusting a program whose job is to open JPEG files to do so is not a
vulnerability.

Absolutely they should. But the fact that they D trust it when it is
not worthy of their trust does not make this a remote vulnerability.

Your logic is flawed, though. Even if we agree to disagree on whether or
not opening an untrusted data file is a trust issue or not, what makes it
a remote vulnerability is the fact that the attacker does not need
privileges on the system. Perhaps, you say, you are giving him privileges
by opening his data file. But you are only giving him privileges to open
that file, not to run arbitrary code.

7/16/05, Derek Martin <code (AT) pizzashack (DOT) orgwrote:
Fri, Jul 15, 2005 at 06:40:42PM -0500, James Longstreet wrote:

Jul 14, 2005, at 9:39 PM, Derek Martin wrote:

This kind of attack has a name already: it is a trojan horse.
<snip>
But is this a remote exploit?

No, it's not an exploit at all. Systems are not vulnerable to it
unless a local user runs an executable.

It seems to me your statement can't be correct, because this is ALWAYS
the case. A local exploit requires that a local user run an
executable. A remote exploit requires that a local user run an
executable, even if that is accomplished merely by booting the system.
All exploits require running code, and code doesn't magically start
itself Running code is required, because it is the very running
code which is being exploited.

I think we have some confusion here. We're talking about two distinct
types of attacks, which do not belong in the same category:
* A user receives an e-mail containing a Trojan executable file, a
exe, a .scr, etc. This is not about exploitation. Is about tricking
the user into running what we want. It is similar to telling someone
they should run del c:\(rm -rf /) to scan for viruses. If I am able
to trick a user into executing this commands I'm not exploiting
anything but his trust and lack of knowledge. It is not an exploit
from a security point of view and has no associated vulnerability.
This attack is pretty much independent on the [e-mail] client we use.

* A user receives an e-mail that exploits a security flaw in the
client software. An e-mail with malformed headers, that exploits a
buffer overflow in a specific [e-mail] client and thus executes its
malicious payload for example. This is indeed exploitation, from a
security point of view. We have a piece of data (exploit), which
exploits a security flaw (design or code) in a specific client.

The only thing it exploits is trust of email (or similar vector).

I think this is also not the case. To exploit essentially means to
use. These attacks USE the users' trust of e-mail in order to USE a
bug to gain access to USE the system for his own purposes That
certainly seems like an exploit to me.

The word exploit has acquired a particular meaning when speaking about
IT Security. I don't think we should include exploiting user's trust
in its scope, as it would make the concept too vague.

Let's imagine for a moment that there is a buffer overflow in
libjpeg that allows an attacker to create a malicious JPEG which
can cause any program using libjpeg to execute arbitrary code.
This should be classified as a remote vulnerability.

We disagree here. The vulnerability is neither truly remote nor
local, in the normal senses as we have defined them here. It is a
different kind of vulnerability altogether. The vulnerability is one
to automatically triggering trojan horses Just as in the case of
the fabled Trojan Horse, there is no vulnerability at all until the
local users make a decision to trust something (data in this case,
rather than a hollowed out horse-shaped monument) from an outside
source.
There is a vulnerability, in the libjpeg library. There is no attack
until the local user decides to trust a particular piece of data.

In this case, the trust is given implicitly rather than
explicitly. This is no different than if I handed you a disk, told
you to run the program on the disk, and you did so -- resulting in the
destruction of your hard drive. Would you call this a remote
vulnerability? course not. But the mechanism is exactly the
same except that some of the minor details are different.

The only difference is the medium used to deliver the trojan horse is
a network instead of a disk, and it is slightly more automated,
because you are prone to automatically view the data out of habit. If
I did hand you a disk and tell you to run the program on it, you would
probably be a lot more wary of doing so than you would of reading your
e-mail, wouldn't you? Especially if you don't know me very well. But
if you were dumb enough to do so, would you call this a remote
exploit? What if I gave you a disk that had an Excel spreadsheet on
it, which contained data designed to take over your system using a bug
in excel Is this a remote exploit? I don't think so. Now I use
the same excel spreadsheet, but I send it to you in e-mail instead of
giving it to you on a disk. In all cases, I have given the data to
you. In all cases, there is no exploit at all, until you, the local
user, decides to trust the data, and run broken code against it. The
only difference is the specific delivery mechanism, and the fact that
the average user implicitly trusts data received in e-mail. Because
really, what choice do they have?

The difference between the hypothetical JPEG flaw and running programs
from a disk, besides the delivery mechanism, is that the first
exploits an actual security flaw in the image-rendering engine while
the later just exploits user's trust. The JPEG flaw exploits a certain
implementation of the JPEG rendering engine. Upon viewing a malicious
JPEG, some applications will be vulnerable while other will just pop
up a message saying the JPEG file is corrupted. The exploit is related
to a specific implementation and product. In the case of the disk,
there is no particular instance of software (code) that is being
exploited. The payload and the attack are totally independent from the
applications used ( System excluded). The Excel example
mentioned is again different from the disk program as it uses and
exploits a specific bug in a specific piece of software.

But this is still not a remote vulnerability. It is a user trust
vulnerability, as you said yourself. And it is a vulnerability (or
susceptibility) to trojan horse data. The fact that the data just
happens to come in via a network is largely irrelevant. A remote user
can, IN N WAY, effect an exploit against this kind of vulnerability
merely by his own action. This exploit can not happen unless you, the
local user, do it for him. This is the essential reason why it is not
a remote vulnerability.

Vulnerabilities properties remain hard to pinpoint and define. A
vulnerability remains however a flaw in a piece of software, not in a
user. An attack is a series of actions enabling an attacker to disrupt
the Confidentiality, Integrity or Availability of the system.
Vulnerability!=Attack An attack can use vulnerabilities (libjpeg
buffer overflow) or can use user's misplaced trust (user running
e-mail attachment).

IMH a term suited for these client-side vulnerabilities would be a
remote vulnerability requiring user interaction. It is remote as being
different from local where the attacker needs system access for its
attack and it is remote because the attacker is not placed on the
system attacked. It requires user interaction because it does :).

Mon, Jul 18, 2005 at 10:49:00AM -0500, James Longstreet wrote:
| We disagree here. The vulnerability is neither truly remote nor
| local, in the normal senses as we have defined them here. It is a
| different kind of vulnerability altogether. The vulnerability is one
| to automatically triggering trojan horses Just as in the case of
| the fabled Trojan Horse, there is no vulnerability at all until the
| local users make a decision to trust something (data in this case,
| rather than a hollowed out horse-shaped monument) from an outside
| source. In this case, the trust is given implicitly rather than
| explicitly. This is no different than if I handed you a disk, told
| you to run the program on the disk, and you did so -- resulting in the
| destruction of your hard drive. Would you call this a remote
| vulnerability? course not. But the mechanism is exactly the
| same except that some of the minor details are different.
|
| It's completely different. If you gave me a program on a disk, I wouldn't
| run it, because I know that programs that I run can do whatever they want
| on my system. That's not because of a bug, it's because that's what a
| computer does -- run programs.

Just as an aside, no.

systems run programs and control access to resources. The
idea that any program can do anything to your system is a strange
one. Systems like Goldberg and Wagner's Janus, or Cowan and co.'s
Subdomain, or heck, even the Java security manager, impose limits on
what a program that you run can do.

That most commercial operating systems lack these sorts of controls is
unfortunate. I would really like to be able to limit what files and
directories my mail client or web browser can touch.

| If you gave me a program on disk and I ran it, I am giving you permission
| to run arbitrary code on my system. Therefore, there is no bug. The
| blame lies solely on me, not on my operating system, computer, or the
| program itself.

Again, the blame lies on your operating system for not letting you do
what you want in a common situation.

That's neither here nor there with regards to the local/remote or
credentialed/anonymous discussion. But I think that on a security
list, we should not udnerestimate the value of S features.

Adam