Long-lived security holes [LWN.net]

It is time, once again, to look at quick distributor response to security holes - or the lack thereof. We could start by poking fun at the distributors which have taken over a week to fix the latest kernel vulnerability - but we won't. The updates probably should have come out more quickly, but, in the end, it was a local denial-of-service vulnerability; it was not the top priority for a lot of administrators.

Let's look, instead, at a fix that took a little longer. Red Hat, Fedora, and Whitebox recently sent out advisories for a buffer overrun in the libpng library; this problem could be exploited by way of a hostile image to run arbitrary code on a victim's system. These distributors are thus running just a little behind Debian, which sent out its advisory on December 19, 2002.

In fact, Red Hat had issued an advisory as well. It just turns out that the problem had not actually been fixed. As a result, Red Hat users were vulnerable to attackers wielding evil PNG images for over two years. This is not the quick response time that is a source of such pride for the free software community.

Of course, one should note that, as far as anybody can tell, not a single Red Hat user suffered any sort of compromise as a result of this unfixed bug. It almost certainly could have remained unfixed for another two years without ill effect. Perhaps the world isn't quite as dangerous as we sometimes think.

The truth of the matter is that our community finds (and fixes) dozens of vulnerabilities every year which are unlikely to ever be exploited. These fixes add to the load of already overworked system administrators and give ammunition to "alert counters" who like to claim that Linux is less secure than other operating systems. Perhaps it is time to come out and admit that many of the patches issued every year are not actually all that important.

System administrators already prioritize updates as they come in. Remotely exploitable holes (should) get fixed in a hurry. Vulnerabilities like this week's aspell hole - a buffer overflow caused by words more than 256 bytes long - can be allowed to sit for a while. It would be nice if distributors could help out by explicitly noting the importance of every update. If the truly serious fixes came with a bright red flag, they might stand out from the noise and be applied more quickly.

There are some obvious problems with this idea. Some truly serious vulnerabilities are not seen as such when they are originally fixed. In certain litigious countries, nobody wants to be exposed to lawsuits from users who were broken into by way of a "non-urgent" vulnerability. These issues would need to be addressed, but the fact remains: we are not necessarily helping ourselves by treating all updates as if they were equally important.

to post comments

Long-lived security holes

Posted Jun 24, 2004 8:27 UTC (Thu) by wichert (guest, #7115) [Link] (11 responses)

As Linux vendors we are well aware of the fact that some security problems are more severe than others. What we would like to do is add some sort
of severity-rating to a vulnerability, much like microsoft already does for their advisories. Unfortunately we got stuck trying to come up with objective criteria for such a rating: there are a lot of factors involved and many of them will differ highly in severity depending on the environment in which a problem can occur. In the end we failed to decide on a single scheme.
If at some point someone can come up with a solid severity rating it is likely that it will be used at some point.

Long-lived security holes

Posted Jun 24, 2004 9:31 UTC (Thu) by mjr (guest, #6979) [Link] (9 responses)

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.

Long-lived security holes

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

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] (5 responses)

> 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 (guest, #1954) [Link] (4 responses)

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] (3 responses)

> 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 (guest, #1954) [Link] (1 responses)

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 (guest, #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 (guest, #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 (guest, #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.

Long-lived security holes

Posted Jun 24, 2004 18:28 UTC (Thu) by pimlott (guest, #1535) [Link]

It's a rat's nest. The best a distributor is likely to be able to do is say, if you're running a "pristine" instance of our OS, with no local or third-party software, here is your risk from untargeted attacks. And even then it is pretty hard to audit all the ways a piece of code could be used (do you consider every application that uses libpng and how it might be an attack vector?). We've been very wrong before about the security implications of bugs. With local software (or even local configuration) added to the mix, the best you can say is that this code is probably not a risk, unless you're using it in a way we didn't think about.

If someone is (or may be) targeting you, a widely-applicable risk assesment is basically useless. You have to figure out how much it would cost to get you, which almost certainly involves local factors (such as people).

A lot of users do use mostly-pristine distributions, and are not targeted by attackers willing to spend much on them (of course, who really knows if he's targeted?), so maybe a risk assessment aimed at them (and clearly labeled as aimed at them) could work. But I fear that after the first "low severity" bug gets widely exploited, people won't have much faith in the rating. I would much rather see aggressive (but careful) bug fixing and timely, fully automatic updates for most users, so they don't even have to think about severity.

Frankly, the most useful information for sophisticated users would be more specifics about the vulnerability and how it can be exploited. Many advisories are disturbingly vague.

Long-lived security holes

Posted Jun 24, 2004 23:59 UTC (Thu) by garloff (subscriber, #319) [Link] (1 responses)

Good recommendation.
SUSE does actually put lines that indicate the severity in their
security announcements:
Vulnerability Type: local privilege escalation
Severity (1-10): 5
I don't know whether there is a published scale for the severity,
but it matched my own feeling about the severity of the issue
quite well. Remote root is 8 -- 10.

Just agree on something...

Posted Jun 30, 2004 6:51 UTC (Wed) by koide (guest, #22687) [Link]

As has already been said, the severity of a bug can't be accurately assessed generically without extensive work. Nontheless, it would be useful for vendors to agree in a common classification of security holes, not using it to describe their severity, but for people to know how can they be triggered and what they are known to do.

Each of the categories should be clearly defined, thus allowing each admin find out how to sort the install order of the packages according to her particular configuration. Package tools could evolve to use this classification to apply the updates in an admin defined order, if there is no defined order, all updates are treated equally, just as happens now.

Even if the things posted here don't cover all possible cases or can't make clear distinctions between each of the categories, they can make a useful start for such a classification. For instance, I think the 'human local account'/'non human local account'/'without account', 'DOS'/'root compromise'/'non root compromise' and 'server'/'client'/'both' distinctions could be part of it.

I think even just a standarized distinction between vendors for the first criteria will help a lot of admins, but I can't prove it :-)

Of course, a classification for this kind of domain ends up being faceted because issues such as 'servers usually have a non human account in the machine, therefore the exploit which uses the server to gain its shell account privileges falls under two categories' often arise, but it is a manageable problem and it gives some extra flexibility when writing rules.