Long-lived security holes [LWN.net]

Long-lived security holes

Posted Jun 24, 2004 9:31 UTC (Thu) by mjr (subscriber, #6979)
In reply to: Long-lived security holes by wichert
Parent article: Long-lived security holes

Hmm; I'd think that something like the following (relatively objective) criteria would be helpful, if not perfect:

- Remote code execution with root priviledges
- Remote code execution with other priviledges
- Remote code execution, user action required¹
- Local priviledge escalation to root
- Local priviledge escalation, other
- Remote DOS, whole system
- Remote DOS, single service
- Local DOS, whole system
- Local DOS, single service

¹ Such as using a buggy program to view malicious content from the web.

(Log in to post comments)

Long-lived security holes

Posted Jun 24, 2004 13:41 UTC (Thu) by DaveK (subscriber, #2531) [Link]

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

Imagine that a user views a file using their usual viewer for that file type which is vulnerable to what would be classified as a localy exploitable buffer overrun (say) and allows either arbitary code execution or priviledge escalation.
if the user views a suitably crafted 'contaminated' file from an external source that is able to escalate its priviledges or execute code, then this comes very close to a remote vulnerability - especially if the program is piped email attachments or perhaps something by a browser that it can't display internaly - 'the UNIX way'.
This becomes more accute the more 'public access' the system is, and the chances of the vulnerability being triggered maliciously increase.

IMHO there are 2 classes of vulnerabilities,

1)Those that allow arbitary code execution, or privilege escalation.
2)Those that cause the affected process to exit or hang without escalation or arbitary code execution.

The first kind could be considered 'compromise capable' and the second 'anoying'.

Long-lived security holes

Posted Jun 24, 2004 16:13 UTC (Thu) by RobSeace (subscriber, #4435) [Link]

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

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?

Long-lived security holes

Posted Jun 24, 2004 18:16 UTC (Thu) by vonbrand (subscriber, #4458) [Link]

Problem with any such proposal is that it is often very hard to see exactly what the implications of a bug are. Sure, found a potential buffer overflow. Is it for real, or is impossible to get there? Is the overflow large enough to inject shellcode? Can an attacker tweak the overflowing data enough to inject shellcode? Or return into something "interesting"? Can he destroy other variables, with unforeseen later efects? And a long etcetera. To fully answer all these questions is a lot of work. Most would just fix it, make sure it is really fixed, and move on.

A long while back I looked over dip (a proggie for connecting via SLIP), found some suspicious code, and sent a patch upstream. It turned out later that this fixed an exploitable root compromise. I just did not have the expertise to check for that (neither did I have the inclination to search for exploits).

At most, you could say the bug is potentially serious... but all bugs are. If the program is SUID, or a network server, it is clearly more dangerous. But even root may run any random program (like more(1)) on non-trusted data, so...

Long-lived security holes

Posted Jun 25, 2004 0:08 UTC (Fri) by DaveK (subscriber, #2531) [Link]

From the (so far) brief discussion here, it seems that since there are so many factors to consider in devising a rating scheme, that such a one will be very difficult to agree upon. Furthermore, as noted above, once a 'low rated' bug gets exploited then the rating may lose its credibility.
So perhaps the focus should not be on a rating system which may lull people into a false sense of security of being able to delay updates, but to accept that all vulnerabilities could have unforseen implications, and should thus be considered serious, and to look instead into the process of distributing and applying fixes, and to make this less painful or intrusive, such that sysadmins have no reason to fear and or delay patching/updating.