| |||||||||||
|
| |||||||||||
Long-lived security holesLong-lived security holesPosted Jun 24, 2004 8:27 UTC (Thu) by wichert (subscriber, #7115)Parent article: Long-lived security holes
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
(Log in to post comments)
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.
|
|||||||||||