|
|
Subscribe / Log in / New account

The security state of Fedora Core 4

Mark Cox has posted a message describing the process that the Red Hat security team went through to verify that Fedora Core 4 was free of known vulnerabilities. They went through several hundred vulnerabilities from the CVE list, and, for each, verified that FC4 was not vulnerable. "For 20030101-20050607 there are a potential 863 CVE named vulnerabilities that could have affected FC4 packages. 759 (88%) of those are fixed because FC4 includes an upstream version that includes a fix, 10 (1%) are still outstanding, and 94 (11%) are fixed with a backported patch."

to post comments

The security state of Fedora Core 4

Posted Jun 13, 2005 21:24 UTC (Mon) by joey (guest, #328) [Link]

The Debian testing security team did a similar review process before the release of Sarge; we checked all CVE/CAN entries since the release of woody (CAN 2002-0654 to CAN 2005-1900; a slightly longer span of time than Fedora checked). Of those 6536 vulnerabilies, 5310 have never affected software in Debian, but 1226 had at some point, affecting 498 different packages.

918 package updates were issued to fix these security holes (some holes affected multiple packages but many updates fixed more than one hole). Of these updates, 287 (31%) were new upstream releases, while approximatly 631 (69%) involved backporting the fix (or applying the fix before a new upstream version was released).

It's interesting that these percentages are so different from Fedora, especially because Debian was open to unstable development for most of the time period we checked and if a new upstream release is available with a fix, it can be easily uploaded while backport type stuff is extra work. One thing that is probably skewing the numbers is that 94 of the backported fixes were non-maintainer uploads (NMUs), which Debian's culture frowns on introducing new upstream versions of a package.

I'm also interested to see that we used very similar methods to Fedora for our check of the CVE list.

The raw data for Debian is here is someone wants to try a better analysis:
svn://svn.debian.org/secure-testing/data

The security state of Fedora Core 4

Posted Jun 13, 2005 21:42 UTC (Mon) by jd (guest, #26381) [Link] (4 responses)

Going against a list of known vulnerabilities is good, but it isn't perfect. (Well, admittedly, unless you want to spend a billion or so dollars on a crack code-auditing legion, I'm not sure what "perfect" would be. :)

I hope, though, that Red Hat and the Fedora Core guys did more than just a walk-through on the known vulnerabilites. There are code validators, malloc replacements that check for overflows and memory leaks, you can even get some good ideas on potential bad spots in the code with -Wall.

What I am hoping is that FC4 is iron-clad, when it comes to security. This is the distribution that will be fighting the hardest on the server front-line against Longhorn, based on typical distribution release cycles, and also based on how the media loves creating fights to the death. If FC4 has serious defects, Longhorn will do better than it would otherwise do, as Open Source is still treated with a lot of suspicion. It doesn't matter if FC4 is the best-ever Linux distro, will cure cancer, and can deduce the phone number of God - if the media decide to love it, it will carve a good-sized nicle for itself in the server market.

If, on the other hand, FC4 can be held up for ridicule, it could spell disaster for it, and give Microsoft an opening to push their "corporate-backed" products even further. Before flaws were uncovered in Firefox and Mozilla, Firefox' approval was rising sharply and could have gained control of the market within a year or two. They might do so still, but probably not this side of five years at best, now.

The security state of Fedora Core 4

Posted Jun 13, 2005 22:58 UTC (Mon) by bojan (subscriber, #14302) [Link]

> What I am hoping is that FC4 is iron-clad, when it comes to security.

That would be awesome, but unfortunately, there is no such thing (yet).

The security state of Fedora Core 4

Posted Jun 14, 2005 0:52 UTC (Tue) by JoeBuck (subscriber, #2330) [Link] (1 responses)

What are you talking about? Fedora is, as far as the industry is concerned, just a beta test for RHEL. Its purpose is not to be perfect; rather it is intended to get leading-edge technology out in the field. It is going to have security bugs, which I'm sure the Fedora team will promptly fix.

Furthermore, Longhorn, when shipped, will have bugs, including some embarrassing ones. No one yet knows how to prevent this.

The security state of Fedora Core 4

Posted Jun 14, 2005 1:30 UTC (Tue) by bojan (subscriber, #14302) [Link]

> Furthermore, Longhorn, when shipped, will have bugs, including some embarrassing ones. No one yet knows how to prevent this.

But that's easy! Just download the source, apply the patches and away you go ;-)

PS. Even Steve Jobs of Apple joked around with release dates of Shorthorn in his WWDC keynote... Nobody beats MS when it comes to delayed and buggy releases :-)

The security state of Fedora Core 4

Posted Jun 16, 2005 7:45 UTC (Thu) by [email protected] (guest, #2303) [Link]

Making sure that we've fixed the vulnerabilities that are already public is hugely important -- it verifies that our daily monitoring through the life of the previous OS did in fact catch all the notifications of issues, it verifies which flaws upstream actually fixed. But as you say this is only a small part of our overall security strategy. We've done fuzzing audits on some critical protocols, all packages in FC4 are compiled with FORTIFY_SOURCE, we have Exec-Shield, PIE, SELinux, malloc control pointer checks, and other innovations designed to add layers of security.

At FudCON 2 next week I'll be presenting more interesting stats as well as looking at exactly what sorts of exploits could have affected Fedora Core 3 users and what we did about it.


Copyright © 2005, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds