Message-ID: <003301c3998c$fab0fc80$78e3a443@datendrao2d5z7>
Date: Thu, 23 Oct 2003 11:42:06 -0600
From: "Eric Knight" <eric@...rdsoft.com>
To: "Steven M. Christey" <coley@...re.org>,
	<bugtraq@...urityfocus.com>, <vuln-dev@...urityfocus.com>
Subject: Re: "Local" and "Remote" considered insufficient


Dear Mr. Christey (and Community):

This problem was addressed on Bugtraq almost 4 years ago in quite a bit of
detail, lets recap however:

> The basic problem is that the terms "local" and "remote" are
> insufficient to identify the nature of the path (and required access)
> through which a vulnerability may be exploited.  It's also important
> to include the amount of "authentication" required, the configurations
> under which the issue exists, whether the attack requires any
> involvement by the user, and the set of entities that can launch an
> attack (one system, many systems, trusted systems, same physical wire,
> anybody who can send a packet, one user, many users, trusted users,
> etc.), and so on.

> For the CVE description style, we have "local" (user is authenticated
> to system), "remote" (non-authenticated attacker across the network),
> "remote authenticated" (traffic goes across the network, but
> authentication is involved), and "physical access."  Older CVE's
> sometimes used "local" to refer to "remote authenticated," but we've
> been better about making the distinction in the past couple years.

Remote Authenticated
Remote Unauthenticated
Local Authenticated
Local Unauthenticated.

This is the beginning of the taxnomy matrix.  Years ago I released a
publication to BugTraq to expand (significantly) the concept of computer
vulnerabilities, the publication has been remarkably successful (well over
100,000 downloads) and is still available either through my web link at
http://www.swordsoft.com/publications.htm or by search engine, I know its
been hosted at a number of different locations.

I'll just recap a little more:

The "underlying nature" to all Vulnerabilities is a question of "Human
Interaction" and "Time Required".  In essence, you'll see this behavior
everywhere in the security industry and they are the foundation of the
execution of vulnerabilities in the "real world".  Remember, computers have
a totally different perception of what's "fast" and "slow" or even what the
result of an attack is.  The result of any vulnerability depends on the
attacker -- so YES, Social Engineering, Policy Oversight, and even Security
through Obscurity (or Security with Inherent Weakness as I like to describe
it) are all vulnerabilities.  They are obvious in their arrangement in
conjunction with everyone's favorite "Logic Errors" that allow fast access
with limited or no human interaction.  The blurred boarders are just -part-
of the conceptualization process.

The other factors (the next level of details of the vulnerability):

Fault -- Why the problem exists (as documented by Aslam, Krsul, and
Spafford) in their pioneering efforts, revised a little in my publication.

Consequence -- the coding and actions required from the point of execution
of the vulnerability to achieve the most desirable result (E.g., if the bug
allows full interactive Administrator access, how?)

Tactic -- How the attack is executed, which is either Physical Access, Local
(Internal Access), Client to Server, Server to Client, or
Man-In-the-Middle -- or in many cases, a combination of these.

Severity -- My preferred definition is "Administrator, Read Restricted,
Local User Access, Spoofing, Non-Detectability, and Denial-of-Service".

Authentication Required -- Does the attacker need to have a successful
authentication to execute the attack.

Consequence confuses people, its just a simple step-by-step logic flow.  If
you get the password file, you try to crack it, extract user names, and any
other useful information, to move toward the next cause. So when you see
"Potential Administrator Access", they usually mean the vulnerability has a
path toward getting the higher access level.

The rest of the details -- platform, medium, application, filenames,
versions, etc. also need to be documented (I did so rigorously with the
2,500 or so vulnerabilities I had to collect into a database in the past)  I
wrote my database for software automation, so I couldn't leave the details
to chance.

There are plenty of examples in the "Computer Vulnerabilities" publication,
I provided examples for everything that I was able to.  I suggest that if
you are proposing a new industry standard taxonomy, you should begin there.

Take care,

Eric Knight
Friendly Neighborhood <broke and poor> Security Researcher

Powered by blists - more mailing lists