Long-lived security holes [LWN.net]

Long-lived security holes

Posted Jun 24, 2004 16:13 UTC (Thu) by RobSeace (subscriber, #4435)
In reply to: Long-lived security holes by DaveK
Parent article: Long-lived security holes

> Is there really any such thing as a truly local only security hole?

Yes, of course there is... What you describe in your example fits mjr's
third classification: "Remote code execution, user action required", and
NOT the 4th or 5th "local" classifications... If you use a vulnerable app
to handle untrusted remote content, then it's certainly NOT a local-only
vulnerability in that app... However, not all apps (or, even close to the
majority of apps) are used to deal with remote untrusted data... For
instance, if there were a bug in "passwd", which gave you root privs if
you typed in a really long password, or something, there's simply NO WAY
that'd ever be exploited remotely... I mean, it's just inconceivable that
there's any method of using remote untrusted data in combination with it,
unless you invent some truly mind-warpingly insane scenario (eg: user is
somehow duped into manually cutting+pasting evil data into passwd)... So,
THAT would be a truly local-only vulnerability... There are countless
other similar examples... Take a look at every binary installed on your
system, and count how many simply make no sense at all to ever be used in
combination with remote untrusted data; I think you'll find it's most of
them...

(Log in to post comments)

Local vs remote exploits

Posted Jun 25, 2004 16:56 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

I don't think local/remote is a useful distinction, and I don't think people mean local and remote when they say it.

If a user telnets into a system and logs in with his legitimate password and then exploits a bug, that's a remote exploitation.

I think most people think "need already to be able to legitimately run a shell program" when they say "local." If so, they should just say that.

The real distinction we want is exploits that require some amount of legitimate privilege vs those that require virtually no privilege. The former are less serious because a smaller number of people, who have already passed some test of trust, can do them.

The ability to legitimately log in to a shell is a certain level of privilege. So is the ability to do a CVS checkout or submit certain http forms, etc.

Local vs remote exploits

Posted Jun 25, 2004 17:24 UTC (Fri) by RobSeace (subscriber, #4435) [Link]

> If a user telnets into a system and logs in with his legitimate password
> and then exploits a bug, that's a remote exploitation.

No, not by any sane definition of "local" and "remote" exploits, it's not...
Like you say, most people use the terms to mean "can be exploited only by
legitimately authorized local users" and "can be exploited by absolutely any
random remote user who can route packets to the machine"... I don't think
those definitions are such a stretch... And, I don't think your bizarre
interpretation of the terms is particularly useful or widespread... Yes, in
your above example, that's a "remote user", from one point of view; but,
when they exploit a hole on the system they are logged into, they are a
"local user" of that system... It doesn't much matter whether they are
coming in over a telnet connection, SSH, modem, or are sitting right at the
console... They still have some form of authorized access to that machine,
and therefore are local users of it...

But, whatever... This is just a semantics argument... No matter whether
you want to call it "local vs. remote" or "authorized vs. unauthorized" or
anything else, the point still stands that there most definitely IS a valid
and very major distinction between the two, and the local/authorized holes
tend to be of FAR less importance to MOST people who have no untrusted
local users on their machines...

Local vs remote exploits

Posted Jun 25, 2004 20:59 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

And, I don't think your bizarre interpretation of the terms is particularly useful or widespread

That's almost word for word what I said, so we agree there. Except that I don't think you can call "bizarre" an interpretation that takes the words "local" and "remote" to mean what they mean in every other context under the sun.

This is just a semantics argument

Exactly. It's important to use the right terminology because people derive a lot of meaning from the bare words. I assure you that if you classify exploits as "remote" or "local," some people will think you mean it in the conventional sense of those words. That would result in less than optimal classification of security exposures.

there most definitely IS a valid and very major distinction between the two

So the only question is, what are the two types you're distinguishing? Calling them by conventional English words would go a long way toward nailing that down. Arbitrarily labelling exploits by partially authorized people "local" and exploits by total strangers as "remote," especially since those words already have meanings ("near" and "far") in other contexts, is just inviting misunderstanding.

Local vs remote exploits

Posted Jun 25, 2004 21:19 UTC (Fri) by RobSeace (subscriber, #4435) [Link]

Even if I were to buy your claim that the terms were technically wrong in
this context (which I don't), I'd still think your argument was silly...
It's on par with people who complain about the usage of "kilobyte" and
"megabyte" and such, because they're power-of-two based rather than
power-of-ten based, when used in a computing context... Words can mean
different things in different contexts; it happens all the time; people
handle it just fine... Does my grandmother know the difference between a
power-of-two "megabyte" and a power-of-ten "megabyte"? No, but she also
doesn't care... The people that NEED to know, WILL know, from the context...

And, "local" and "remote" in regards to vulnerabilities have been used for
many years in this way, with no one that I've ever seen (until now) confused
or annoyed about them... (The same way kilobyte/megabyte/etc. worked just
fine with no confusion for anyone for years, until some uptight, humorless
party-poopers came along and made up the silly "kibibyte", "mebibyte", etc.
nonsense, and tried to force it down everyone's throats...)

But, even arguing on technical correctness of the terms, I don't think you
have a case... The user IS local to that machine; even if they're loggging
in from a remote machine! They're still a LOCAL user on that destination
machine... Local, as in local to that machine... As in, listed in that
machine's local "/etc/passwd", with a home directory on its local disk,
and with privileges to run programs on its local CPU... I don't think
calling them "local users" is out of line with reality...

Local vs remote exploits

Posted Jun 25, 2004 22:08 UTC (Fri) by Ross (subscriber, #4065) [Link]

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?