Likes: 
In a recent post, Florian Weimer said:
>> PACKAGE : ircd
>> SUMMARY : Local denial of service vulnerability
>
>Actually it's *remote* in the usual terminology on this list.
>
>[snip]
>
>When IRC server developers talk about "local vulnerabilities"
>vs. "remote vulnerabilities", they mean the distinction given above
>(exploit over local connection vs. exploit over the IRC network). In
>the terminology with which most readers of this list are familiar,
>both attack vectors are "remote". "Local" attacks come from
>authenticated users or users with shell access.
These types of discrepancies in terminology happen fairly often.
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.
In CVE, we've generally had to deal with the "impreciseness" of local
vs. remote terminology for a while.
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.
There are still some complexities, however.
When authentication comes into play, one must consider: authentication
to *what* ? If a bulletin board requires someone to "authenticate" as
an administrator for that board, but the access is restricted to the
bulletin board itself (i.e. not the rest of the system), is that a
"local" vulnerability or a "remote" vulnerability? (It's "local" to
the application but "remote" across the network.) What if the
bulletin board administrator, by design, can execute operating system
level commands as some "user" on the operating system?
When an FTP bug is exploitable by "authenticated" users, but the FTP
server allows guest/anonymous login, then is there really
"authenticated" access required? What if the affected protocol allows
man-in-the-middle attacks?
The scope of a bug can also be restricted to a smaller set of
"trusted" machines or accounts. Think of the GUIs of routers and
firewalls, which (in a perfect world) are generally only accessible to
a small number of trusted hosts. Think of bugs in domain controllers
that can only be exploited by other domain controllers. Are those
vulnerabilities really "remote?"
And how about bugs in software that's used to package files for
transport such as tar, zip, etc.? The bug is "local" in the sense
that the packaged file has to reside on the local system in some way,
and only an authenticated user can run it to install it on the system,
but these formats are commonly used for transferring files from
machine to machine, so they're "remote."
Then you have bugs in non-setuid programs that are only exploitable
from a local user, but those programs are often called from remotely
accessible processes (e.g. a recent buffer overflow in a "whois"
client that's commonly called by CGI programs). As another example,
consider a database bug that's only exploitable by "local" database
users, but the database also has a default password and is remotely
accessible (in this case, I view it as the interaction of two separate
issues).
So, to echo Florian's comments, "local" and "remote" is not sufficient
in fully evaluating the severity of a vulnerability in a particular
environment.
- Steve
P.S. Credits to Adam Shostack and Scott Blake for initially educating
me about the role of authentication in "local" vs. "remote"
terminology.
Quote
=20
