Weekly Edition
Return to the Security page
| |||||||||||
|
| |||||||||||
Long-lived security holes
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. (Log in to post comments)
Long-lived security holes Posted Jun 24, 2004 8:27 UTC (Thu) by wichert (subscriber, #7115) [Link] 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 sortof 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 (subscriber, #6979) [Link] Hmm; I'd think that something like the following (relatively objective) criteria would be helpful, if not perfect:- Remote code execution with root priviledges ¹ 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 (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. IMHO there are 2 classes of vulnerabilities, 1)Those that allow arbitary code execution, or privilege escalation. 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
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... But, whatever... This is just a semantics argument... No matter whether
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 inthis 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 But, even arguing on technical correctness of the terms, I don't think you
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 thedata 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 Not all exploits are the same. Many allow running arbitrary code. But arbitrary execution as root Now assign numbers to each item in each list. A vulnerability can be There's a lot of ways to do this and that's just an example I threw In the complete absence of ratings it would be nice if advisories would
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.
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] 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.
|
|||||||||||