Software::Distributionen::Red Hat
Sicherheitsstatistik zu Red Hat Enterprise Linux 4
Vier Jahre nach der Freigabe von Red Hat Enterprise Linux 4 hat Mark Cox im »Red Hat Magazine« eine Zwischenbilanz zu den Sicherheitsrisiken der Distribution gezogen.
Der Bericht ist eine Aktualisierung des vor einem Jahr erschienenen Berichtes nach drei Jahren Red Hat Enterprise Linux 4 (RHEL 4).
In den letzten zwölf Monaten hat Red Hat 107 Sicherheitsupdates für RHEL 4 herausgebracht, die 251 Probleme korrigierten. Das ist laut Cox auf den ersten Blick viel, doch geben die Zahlen nur den schlimmsten Fall an, der nur eintreten kann, wenn alle in der Distribution enthaltenen Pakete installiert sind. Außerdem wären nach diesen Zahlen alle behobenen Sicherheitslücken gleich schwerwiegend, tatsächlich waren jedoch nur wenige kritisch.
Red Hat bewertet die Risiken der Sicherheitslücken auf einer vierstufigen Skala: Low (niedrig), Moderate (moderat), Important (wichtig) und Critical (kritisch). Die Sicherheitslücken, von denen RHEL 4 betroffen war, summieren sich in vier Jahren auf 1269 in einer Maximalinstallation mit allen Paketen. Davon waren 130 kritisch, 360 wichtig, 484 moderat und 295 niedrig. In der Standardinstallation des RHEL-Servers und der Workstation liegen die Zahlen niedriger, aber nicht viel niedriger. Dabei sticht jedoch die Zahl von nur 10 kritischen Lücken im RHEL-Server heraus. Diese kommt dadurch zustande, dass die meisten kritischen Fehler in Desktop-Programmen wie Mozilla, Firefox und Helixplayer auftraten, die nicht zur Standardinstallation des Servers zählen.
87% der gesamten kritischen Fehler wurden innerhalb eines Tages nach Veröffentlichung der entsprechenden Sicherheitslücke repariert, also Updates zur Verfügung gestellt. Im Durchschnitt waren die Anwender nur 1,6 Tage lang einem Risiko durch die Lücken ausgesetzt, bei Server-Software nur 0,6 Tage. Nach diesen Zahlen hat Red Hat also das Tempo bei der Behebung von Problemen gegenüber dem letzten Jahr noch erhöht.
Im Gegensatz zu Anbietern proprietärer Software hat Red Hat in den meisten Fällen keinen Einfluss darauf, wann eine Sicherheitslücke publik gemacht wird. Nach Ansicht von Cox ist das gut so. Der Distributor ist dadurch gezwungen, schnell zu reagieren, und kann keine Spielchen mit dem Zurückhalten von Informationen treiben.
Cox macht auch Angaben darüber, auf welchem Weg Red Hat von Sicherheitslücken erfahren hat. In 51% der Fälle wurde Red Hat vorab informiert. Die Information kam in 22,5% aller Fälle von den Entwicklern der Software und in 19,6% der Fälle von anderen Distributoren. Oft konnte Red Hat aber erst reagieren, nachdem die Sicherheitslücke bereits publiziert wurde - in 24,6% der Fälle auf Mailinglisten und in 13,7% der Fälle durch andere Distributoren.
Interessanter als die Zahl der Sicherheitslücken ist laut Cox das Risiko, das sich unter anderem in der Zahl der kursierenden Exploits äußert. Demnach beobachtet Red Hat zahlreiche Quellen und hat daraus eine Statistik erstellt, die auch Exploits erfasst, die nur zur Erläuterung des Konzepts dienen und nicht direkt brauchbar sind. Denial-of-Service-Angriffe wurden ausgeklammert. Von den 59 erfassten Exploits bezogen sich 9 auf den Kernel, 19 auf Browser, 9 auf PHP, 10 auf Server-Software und 15 erforderten eine aktive Beteiligung eines arglosen Nutzers. 40% dieser Lücken, so Red Hat, nutzte Pufferüberläufe, deren Ausnutzung durch Exec-Shield nahezu unmöglich gemacht wird. Mit RHEL 4 wurde zudem SELinux standardmäßig aktiviert. Alle PHP-Exploits konnten durch SELinux in ihrer Auswirkung begrenzt werden.
Die von Red Hat verwendeten Daten für die Statistik sind öffentlich zugänglich.
