Local vs remote exploits
Posted Jun 25, 2004 22:08 UTC (Fri) by
Ross (subscriber, #4065)
In reply to:
Local vs remote exploits by RobSeace
Parent article:
Long-lived security holes
Local and remote are not enough. There are also "local" problems where the
data is coming from a remote server. Email clients, web browsers, etc. are
run by the user, as the user, but they process untrusted data. So I see it
something like (from highest to lowest severity):
remotely explitable server
remotely exploitable client
locally exploitable server running as root or system user
locally exploitable server running as the user
locally exploitable client or non-networked program (suid/sgid)
often-used directly or in scripts, locally exploitable client or non-networked program (non-suid, non-sgid)
rarely-used directory or in scripts, locally exploitable client or non-networked program (non-suid, non-sgid)
Not all exploits are the same. Many allow running arbitrary code. But
some only allow reading or deleting files. Futhermore you have to take
DoS attacks into account. This is like a separate ranking:
arbitrary execution as root
file or memory viewing as root
file deletion or modification as root
arbitrary execution as a system user
file or memory viewing as a system user
file deletion or modification as a system user
arbitrary execution as a user
file or memory viewing as a user
file deletion or modification as a user
system-wide denial of service (crash, lockup, etc.)
permanent (until manual intervention) remotely visible denial of service
temporary remotely visible denial of service
partial remotely visible denial of service (performance impact only)
other permanent (until manual intervention) denial of service
other temporary denial of service
other partial denial of service (performance impact only)
Now assign numbers to each item in each list. A vulnerability can be
assigned a severity ranking by choosing the closest match in each list
and multiplying the assigned numbers.
There's a lot of ways to do this and that's just an example I threw
together. The point is that almost any raking would be better than what
we have now.
In the complete absence of ratings it would be nice if advisories would
clearly state what the threat is so that administrators can make their own
determination without a lot of guesswork. Does it allow aribtrary code
execution? Does it just crash the service? Who can exploit it? Are there
known exploits in the wild?
(
Log in to post comments)
