Weekly Edition
Return to the Security page
| |||||||||||||
Enterprise Linux 5.3 to 5.4 risk report
Red Hat's director of security response, Mark J. Cox, has released another of his risk reports, this one looking at the security updates between RHEL 5.3 and 5.4. He notes that of the nine vulnerabilities of "critical" severity in that time, seven were for Firefox. It is interesting to note that the three NULL pointer vulnerabilities for the kernel were not rated as critical as they were not remotely exploitable. He also points out that three flaws which would have required critical updates, instead required no update—or in one case a low severity update for a denial of service—due to various mitigations (FORTIFY_SOURCE and hardened malloc/free) present in RHEL.
(Log in to post comments)
Enterprise Linux 5.3 to 5.4 risk report Posted Sep 7, 2009 18:42 UTC (Mon) by trasz (guest, #45786) [Link]
Not critical, because not _remotely_ exploitable? Geez. Even Microsoft doesn't try to mask security problems that way.
Enterprise Linux 5.3 to 5.4 risk report Posted Sep 7, 2009 18:51 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]
Classification is not masking but indicates the threat level and therefore the prioritization of fixes and described in more detail at
http://www.redhat.com/security/updates/classification/
I am sure you will agree that a remote exploit is more critical than a local exploit.
Enterprise Linux 5.3 to 5.4 risk report Posted Sep 7, 2009 19:02 UTC (Mon) by spender (subscriber, #23067) [Link]
I don't agree. How many of your servers are going to get hit with a firefox remote? Do they even have X installed? How many of your servers use php code which is almost certainly buggy in some way? Say you're hosting 100 users all with their own php code. A vulnerability in any single one of those sites essentially means a remote root (as kernel locals can be found by closing your eyes and throwing a dart at a map).
It's just not always the case that a remote is more critical than a local bug, as it ignores a huge number of things about the attributes of the exploit. Is it a vulnerability that's difficult to exploit reliably? How long would it take someone to develop a reliable exploit? Fully weaponized null ptr dereference exploits for the kernel take less than 5 minutes to develop. Reliable remote heap overflows (particularly when there are defensive measures in place) take much longer to write.
So these classifications and "risk reports" are generally useless and disingenuous (graphing number of advisories instead of number of vulnerabilities).
-Brad
Enterprise Linux 5.3 to 5.4 risk report Posted Sep 7, 2009 20:35 UTC (Mon) by mjcox@redhat.com (subscriber, #31775) [Link]
One of the problems with the simple severity scale is kernel local privilege escalation flaws at the same "important" severity as a local crasher. So for 2009 vulns we've been providing base CVSS scoring; if you're interested just in privilege escalation flaws (kernel or otherwise) you can just extract all those ones that have been fixed for some given RHEL version, look which ones were 0day, look how long they took to get addressed and so on. You can use CVSS temporal metrics to adjust the scores based on availability of exploit and so on and any given customer can use the environmental modifiers to help them figure out if they care about this issue or not. http://www.redhat.com/security/data/metrics/cve_dates.txt
So for example with CVE-2009-2692 you get a base score of 7.2 (AV:L/AC:L/Au:N/C:C/I:C/A:C) with an initial temporal score of 6.8
Enterprise Linux 5.3 to 5.4 risk report Posted Sep 7, 2009 19:14 UTC (Mon) by PaXTeam (subscriber, #24616) [Link]
> I am sure you will agree that a remote exploit is more critical than a local exploit.
as a blanket statement, that's easily shown to be wrong. think of service providers who give local code execution access to their users (be that a web service, or traditional shell, etc). they couldn't care less about remotely exploitable bugs since they already give away local access. they do very much care about local privilege elevation however as that's what makes or breaks their business.
the second obvious situation is virtualization. a local kernel/hypervisor bug will directly translate to someone else's 'remote' compromise. how do you account for that in your scheme? speaking of which, how do you account for KVM bugs? or do they not exist because noone bothers to analyze them for exploitability?
Enterprise Linux 5.3 to 5.4 risk report Posted Sep 8, 2009 9:53 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]
Eh, nothing is absolute but since a vendor has to prioritize fixes, a remote exploit has to be fixed first. That was the context.
Enterprise Linux 5.3 to 5.4 risk report Posted Sep 9, 2009 19:35 UTC (Wed) by PaXTeam (subscriber, #24616) [Link]
i don't think any linux vendor is in the business of fixing exploits. but beyond that, it's ultimately not the vendor's call to prioritize fixes, but rather that of their customers (also known as 'money talks'). last but not least, you didn't tell me how you guys characterize KVM bugs (take today's 2.6.30.6 release for an example... oh wait, no CVEs).
Enterprise Linux 5.3 to 5.4 risk report Posted Sep 11, 2009 6:14 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]
I have no idea what you mean that Linux vendors are not in the business of
fixing exploits. They certainly do fix exploits and they have to prioritize the fixes as well. Not all fixes need to originate from a vendor however. Every program with multiple security exploits has to find a way to prioritize fixes. You don't seem to have offered any better solution. Do you have one?
I don't see why I should tell you how to characterize a particular security
Enterprise Linux 5.3 to 5.4 risk report Posted Sep 11, 2009 11:45 UTC (Fri) by spender (subscriber, #23067) [Link]
#1: You are talking to the expert
#2: He was hinting that you don't know the difference between vulnerability and exploit. Vendors fix vulnerabilities, not exploits.
-Brad
Enterprise Linux 5.3 to 5.4 risk report Posted Sep 11, 2009 14:47 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]
1) Can the expert answer the question on what either a project or a vendor
should do rather than prioritize fixes. Someone has to deal with multiple vulnerabilities at the same time. Classification and prioritization is how every vendor deals with that. Is the expert offering something better?
2) Must have been much easier to convey the information directly then. I
Enterprise Linux 5.3 to 5.4 risk report Posted Sep 12, 2009 10:15 UTC (Sat) by PaXTeam (subscriber, #24616) [Link]
1. it's a strawman: noone (not me at least) questioned the need for prioritization. what was questioned however is the *basis* for said prioritization. i gave you examples when the current practice of 'it is a kernel bug so it is not critical' mindset is *obviously* wrong.
2. i told you already: you ask your *customers*. and if they tell you that a user assisted firefox bug (local userland, not immediately wormable, i.e., it fails your 'critical' criteria) is critical to *them*, you treat them that way. ditto for KVM bugs (of course it doesn't help when said bugs are not analyzed for security impact and/or swept under the carpet as per current linux security bug handling practice).
Enterprise Linux 5.3 to 5.4 risk report Posted Sep 12, 2009 12:30 UTC (Sat) by nix (subscriber, #2304) [Link]
#2 is unlikely to work: many customers will either spend weeks deciding
how to answer (by which point you fixed the bug long ago), or say 'oh yes it is critical' about *every* bug, because deciding anything else would take too long and deciding that everything is critical reduces your legal risk (or your political rear) should you be wrong.
(But maybe RH *does* do that with some customers, those that pay a lot and
Enterprise Linux 5.3 to 5.4 risk report Posted Sep 12, 2009 14:05 UTC (Sat) by PaXTeam (subscriber, #24616) [Link]
are you on or off your drugs this time? or more to the point, why are you speculating about things you have no idea about?
Enterprise Linux 5.3 to 5.4 risk report Posted Sep 12, 2009 14:53 UTC (Sat) by nix (subscriber, #2304) [Link]
Wow. I knew you were offensively unpleasant and went to great lengths to
avoid actually answering questions, but I had no idea you could be *this* nasty.
Why are you even here? You seem to do nothing but complain...
Enterprise Linux 5.3 to 5.4 risk report Posted Sep 12, 2009 16:14 UTC (Sat) by PaXTeam (subscriber, #24616) [Link]
> Why are you even here? You seem to do nothing but complain...
that was kinda my question to you actually, but i guess you haven't quite got it as usual ;).
Enterprise Linux 5.3 to 5.4 risk report Posted Sep 12, 2009 19:47 UTC (Sat) by foom (subscriber, #14868) [Link]
Keep it civil, please. That kind of comment has absolutely no place here.
Enterprise Linux 5.3 to 5.4 risk report Posted Sep 12, 2009 20:54 UTC (Sat) by nix (subscriber, #2304) [Link]
I *think* he was referring to my periodic brushes with the gods of
anaphylactic shock, in which case it's a bit less unpleasant (but still stupid: it's September, hayfever season is over). I don't think he really *does* 'civil'. Virtually every comment he posts is in some way adversarial.
Enterprise Linux 5.3 to 5.4 risk report Posted Sep 12, 2009 16:39 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link]
Sorry but asking your customers is never going to work as a method in
general for fixing security problems for Red Hat. With millions of customers, you won't ever get useful answers from the majority. They are already paying the vendors to make the technical judgement and do the work. Good luck with that approach.
Enterprise Linux 5.3 to 5.4 risk report Posted Sep 7, 2009 20:23 UTC (Mon) by lkundrak (subscriber, #43452) [Link] Please check facts before commenting. Red Hat's rating roughly corresponds to Microsoft's one. And according to it a vulnerability is critical when its exploitation could allow the propagation of an Internet worm which basically means it can be exploited by remotely without an authentication.
Enterprise Linux 5.3 to 5.4 risk report Posted Sep 9, 2009 19:23 UTC (Wed) by PaXTeam (subscriber, #24616) [Link]
> Please check facts before commenting.
let me try: what about CVE-2009-0081? it kinda defeats your argument, doesn't it? ;)
|
|||||||||||||