A security analysis of two years of RHEL 4
A default installation of Enterprise Linux 4 AS was vulnerable to only 3 critical security issues in the whole two years." It is, overall, a good exercise in transparency by a distributor.
Posted Apr 18, 2007 23:56 UTC (Wed)
by hazelsct (guest, #3659)
[Link] (7 responses)
Is there a similar resource describing Windows server vulnerabilities? I know they have let many holes go unpatched for weeks. The best I can find is Secunia, but they don't have days vulnerable, just fraction currently open (RedHat AS 4: 0%, SUSE Linux 9.0: 1%, Windows 2003 Server Standard Edition: 8%!).
Note the recent remote DNS hole has been unpatched for almost a week, with exploits circulating for half of that time, and Microsoft's advisory still says:
Anyway, my employer is in the middle of a Linux vs. Windows server decision, and I want to, you know, "get the facts".
Posted Apr 19, 2007 0:41 UTC (Thu)
by bojan (subscriber, #14302)
[Link] (6 responses)
Or in plain talk, Microsoft don't give a rat's arse if your box is secure or not. I think your employer may understand that.
Posted Apr 19, 2007 12:22 UTC (Thu)
by tialaramex (subscriber, #21167)
[Link] (5 responses)
The cause Jeff likes to concentrate on is the fact that with so many different distributions, all re-packaging and possibly patching upstream software from many sources, it can be hard to know whether CVE-2010-0428 affects Joe's Linux 4.2 Community Warrior edition, and if they don't know, Secunia counts that as a "not affected". So often the first time that Secunia know RHEL 4 is affected by a particular issue is when Red Hat issue a security update for it. That shows up as "zero exposure" but the reality is different. I don't think this is the only cause for the difference by any means, but it should be taken into consideration.
It would be interesting to hear some opinions of Jones from anyone who knew him prior to Microsoft. He seems genuinely excited about his data comparing Linux distributions, OS X and Windows, but the accompanying comments often make me wonder if this is just a propaganda exercise. Did he expect readers not to notice that the Firefox security fix which took "months" in RHEL recently was barely a fix at all, some Firefox developers even argued against bothering with it? I suspect that any similar tweak in Internet Explorer would be considered just a functional change, a non-critical update that happened to have some security benefit. Yet Jones links it via the sensational (but ultimately only tangentially related) MySpace login theft security reports.
Posted Apr 19, 2007 23:02 UTC (Thu)
by bojan (subscriber, #14302)
[Link] (1 responses)
http://securebar.secure-tunnel.com/cgi-bin/nph-freebar.cg...
In particular, Jeff claims:
> At the end of the 90 day period, a total of 85 publicly disclosed vulnerabilities did not yet have a patch from Red Hat 30 from before the product shipped and another 55 disclosed during the period.
Would be nice to get some feedback from Red Hat folks regarding this. Anyone?
Posted Apr 19, 2007 23:18 UTC (Thu)
by bojan (subscriber, #14302)
[Link]
Don't pay any attention to that stuff. Just Jeff being a Microsoft employee, I guess.
Posted Apr 19, 2007 23:15 UTC (Thu)
by hazelsct (guest, #3659)
[Link]
Unfortunately, it is very short on specifics. The full report has several footnote superscripts, without the footnotes anywhere in the report. For example, on RHEL 4:
Thanks for the hint. If this is the best Microsoft can do, we're in good shape.
Posted Apr 20, 2007 3:24 UTC (Fri)
by bojan (subscriber, #14302)
[Link] (1 responses)
After reading Jeff's blog and the report a little bit more, I have to admit that I'd like to know how Jeff decided that particular disclosed but unpatched vulnerabilities _were_ affecting particular Linux flavours he mentioned in his report. His I-ran-rpm-to-see-what's-installed explanation is pretty lame.
For example, if a distro compiles out certain parts of the kernel (most definitely the case with RHEL), how can a vulnerability in that part of the kernel affect the system? Ditto other software. He never explains that kind of stuff.
Jeff's a bit short on details...
Posted Apr 23, 2007 11:53 UTC (Mon)
by tialaramex (subscriber, #21167)
[Link]
* Wait a year or two
This is an admirably cynical approach (wait for vendors to admit to their own problems by publishing fixes for them) but it obviously makes some serious assumptions that could do with a second look.
Posted Apr 19, 2007 3:51 UTC (Thu)
by arjan (subscriber, #36785)
[Link] (16 responses)
Posted Apr 19, 2007 8:38 UTC (Thu)
by mjcox@redhat.com (guest, #31775)
[Link] (1 responses)
The other technology in Exec-Shield certainly blocks a lot of specific exploits, but it's non-deterministic that it would block every possible exploit for a given the particular vulnerability, so we keep the rating as critical.
A lot of the issues in Firefox are more application errors (like javascript running outside of constraints), ones that our security technologies wouldn't catch. So bypassing Exec-Shield and SELinux, the "easiest" way to exploit an unpatched RHEL4 box would be to get the victim using the box to visit your malicious site, with Firefox, exploit one of the javascript-related flaws, then use one of the old privilege escalation exploits to get root.
Posted Apr 19, 2007 13:25 UTC (Thu)
by tialaramex (subscriber, #21167)
[Link]
Posted Apr 19, 2007 20:16 UTC (Thu)
by PaXTeam (guest, #24616)
[Link] (13 responses)
Posted Apr 19, 2007 20:19 UTC (Thu)
by arjan (subscriber, #36785)
[Link] (12 responses)
The first part takes the actual circumstances of the exploit into account (say, the maximum number of bytes the buffer gets overflown is 10 bytes) while the later is a generalization and not relevant to the topic at hand.
Posted Apr 19, 2007 20:36 UTC (Thu)
by arjan (subscriber, #36785)
[Link] (4 responses)
Posted Apr 19, 2007 20:50 UTC (Thu)
by PaXTeam (guest, #24616)
[Link] (3 responses)
second, as another commenter said, the double-free check doesn't prevent exploitation, it just makes it depend on a particular memory layout/content which may be hard or even impossible to achieve in a given situation, but without a thorough examination in every single case, you can't make a blanket statement like that - or if you do, better provide analysis of a few such bugs.
third, code execution is independent of double free exploitation - one is a bug class, the other is an exploit technique (i.e., one of many). what a double free gives you is a sort of 'mirrored write 4/8 bytes anywhere in writable memory' primitive. whether the exploit writer exploits it for code execution or something more subtle depends on what is better (and possible) for his goals. for non-control flow hijacking attacks i suggest that you read http://www.usenix.org/events/sec05/tech/chen.html .
Posted Apr 19, 2007 20:59 UTC (Thu)
by arjan (subscriber, #36785)
[Link] (2 responses)
Second, I said that the glibc checks make most double free attacks effectively impossible, because what happens in the double free (as opposed to the general heap chain corruption case) is that the free'd elenment no longer is part of the chain AT ALL anymore, so the chain checks will just catch this. (In the general heap chain corruption scenario you can argue you can plant those values, in the specific double free scenario you can't argue that)
third, in the context of this article it's about the highest class of bugs, which do imply code execution or information leak as effect.
Posted Apr 19, 2007 22:22 UTC (Thu)
by PaXTeam (guest, #24616)
[Link] (1 responses)
Posted Apr 20, 2007 1:16 UTC (Fri)
by bojan (subscriber, #14302)
[Link]
Maybe there weren't any? Given that all this stuff has been done by Red Hat, maybe all involved just had a private exchange and decided to do it. Or something like that...
Posted Apr 19, 2007 20:37 UTC (Thu)
by PaXTeam (guest, #24616)
[Link] (6 responses)
> Sadly there is very little comment on how many if those critical issues
that's a very strong statement, better back it up with facts.
Posted Apr 19, 2007 20:39 UTC (Thu)
by arjan (subscriber, #36785)
[Link] (5 responses)
Posted Apr 19, 2007 20:57 UTC (Thu)
by PaXTeam (guest, #24616)
[Link] (4 responses)
Posted Apr 19, 2007 21:01 UTC (Thu)
by arjan (subscriber, #36785)
[Link] (3 responses)
I think you're acting a bit too paranoid here...
Posted Apr 19, 2007 21:17 UTC (Thu)
by PaXTeam (guest, #24616)
[Link] (2 responses)
PS: no need for ad hominem.
Posted Apr 19, 2007 23:01 UTC (Thu)
by k8to (guest, #15413)
[Link]
Posted Apr 20, 2007 1:37 UTC (Fri)
by bojan (subscriber, #14302)
[Link]
After re-reading all Arjan's comments, I think Arjan believes these two technologies _could_ provide protection against those critial issues, not necessarily that they _would_. No?
Wow, an outstanding record, particularly regarding first-day fixes and days of vulnerability.A security analysis of two years of RHEL 4
Astounding...
I visited Secunia web site occasionally in the past, just to see how things were going wrt. RHEL. At any given time I visited, RHEL would have zero unpatched security issues listed by Secunia. Various Microsoft products would have many.A security analysis of two years of RHEL 4
Jeff Jones at Microsoft claims that Secunia's tracking is ineffective for Linux distributions like RHEL. He's even published some figures on it.A security analysis of two years of RHEL 4
I'm guessing you are referring to this:A security analysis of two years of RHEL 4
Oh, any Jeff also make sensationalist claims like "On the day of the release, Red Hat published X number of security advisories for RHEL." I'm guessing he would like that people think negatively about that, when it's actually a good thing (i.e. Red Hat were fixing bugs during the freeze period).A security analysis of two years of RHEL 4
Thanks. I googled "Jeff Jones secunia" and found his website. Most prominent right now is the Vista 90-day vulnerability report dated yesterday, which purports to show that Vista's vulnerability profile is vastly lower than those of RHEL 4 WS, Ubuntu 6.06 LTS, Novell SLED 10, or Mac OS X 10.4.A security analysis of two years of RHEL 4
I have to contrast this with RedHat's report and conclude that, with lots of detail in the RedHat report and none whatsoever in the Jeff Jones report (package lists, disclosure dates, fix dates), Jeff Jones is full of it. I'm posting a comment to that effect on the site.
> it can be hard to know whether CVE-2010-0428 affects Joe's Linux 4.2 Community Warrior editionA security analysis of two years of RHEL 4
My understanding from reading Jeff's work, which certainly shouldn't be any replacement for asking /him/ to make it clearer, is that his process for figuring what the vulernabilities were in non-Microsoft products is...A security analysis of two years of RHEL 4
* Read list of security advisories from vendor
* Note down every security bug fixed
* Identify when these bugs were first reported in any venue
* Measure elapsed time (or zero if negative) between when the bug was reported and when it was fixed.
Sadly there is very little comment on how many if those critical issues were actually.. well effectively impossible to exploit due the security technologies.Exec-Shield and SELinux
Could well be the vast majority of them....
Where a technology completely blocks the ability to exploit the flaw in a deterministic way we'll decrease the severity -- there were a couple of double-free flaws in krb5 that would on earlier RHEL be classed as critical but on RHEL4 and above we can show they cannot be exploited.Exec-Shield and SELinux
For a double-free, how reliable is your analysis in the face of unlikely but possible allocation patterns elsewhere? Obviously in the trivial case of a single threaded program which does { free(foo); free(foo); } we can see that a double-free detection will work effectively. In real world programs the two calls to free() may be quite distant, and there may be other threads running which also use the allocator. For obvious reasons you can't track all free'd memory indefinitely, so presumably there must be cases where a double-free exploit is still possible.Exec-Shield and SELinux
what security technologies does RHEL4 have that make exploitation impossible? neither of those mentioned in the subject provides such a guarantee.Exec-Shield and SELinux
you're misquoting me.. I did not say "impossible" I said "effectively impossible". There is a huge gap between "not exploitable in practice" and "not exploitable as a class as a whole in theory".Exec-Shield and SELinux
maybe as example to illustrate: the double-free protection that got added to glibc as part of the Exec-Shield project makes *most* double free attacks effectively impossible, because while a remote person may be able to trigger a double free, the checks in glibc remove so much freedom that it's no longer exploitable for executing code.Exec-Shield and SELinux
first, the double-free protection was published by Stefan Esser (http://www.derkeiler.com/Mailing-Lists/securityfocus/bugt...) and used in at least Gentoo prior to its incorporation in glibc, it had nothing to do with Exec Shield.Exec-Shield and SELinux
yes double free checking as concept wasn't new. Getting a whole set of that into glibc was part of the Exec-Shield project. I find it curious that you claim it wasn't... I don't remember you being part of that project.Exec-Shield and SELinux
to me Exec-Shield is this: http://people.redhat.com/mingo/exec-shield/ . if you have other projects under this umbrella, i must have missed their public announcements and the related discussions. can you point to some URLs where these glibc hardening and other discussions took place (i don't mean the cvs commit logs, but the actual design/implementation stuff)?Exec-Shield and SELinux
> must have missed their public announcements and the related discussionsExec-Shield and SELinux
i wasn't quoting you actually, but apparently 'effectively' means different things for different people (much like the "effective protection" term in the DMCA :-). that said, you still didn't answer my question under your interpretation. your original comment would now be rephrased as:Exec-Shield and SELinux
> were actually.. well not exploitable in practice due the security technologies.
> Could well be the vast majority of them....
I can back my statement up with facts easily: there was no comment about how many become practically exploitable in the article. You appear to read a lot more in my comment than there is.Exec-Shield and SELinux
that was only one part of your statement. the other and much more important one is the last sentence where you allude to your belief (or knowledge? i'm still trying to find out) that the majority of these bugs were not exploitable in practice - that's the strong statement (belief?) that needs proof or backing up with facts or plausible analysis. Exec-Shield and SELinux
I did not make such a statement. I said that I'd like to see how many of these type there were. YOU draw the conclusion about that I then think there are many of these, and then claim that that needs careful analysis on MY part before I can say that. Guess what... I was asking effectively if such analysis had been done and if there were numbers.Exec-Shield and SELinux
sure you did: first you clarified that 'effectively impossible to exploit' meant 'not exploitable in practice' then you said that the majority of these bugs could be in that category. now you tell me why you would make a post with two of those technologies in the subject if you didn't believe they would provide this level of protection...Exec-Shield and SELinux
colorful language does not an ad-hominem make.Exec-Shield and SELinux
> now you tell me why you would make a post with two of those technologies in the subject if you didn't believe they would provide this level of protection...Exec-Shield and SELinux