© V. J. Matthew, 123RF.com

Verwundbarkeiten, Patches, Bugfixes, Zertifizierungen: Bei Red Hat und Suse arbeiten spezialisierte Security-Teams daran, Fehlern, Bugs und Schwachstellen rechtzeitig beizukommen.

Die rechte Ferse war es bei Achilles [1], bei Siegfried aus der Nibelungensaga eine Stelle am Rücken. Beide, sonst unverwundbar, besaßen eine bedrohliche Schwachstelle. Eine kleine nur, beim einen der Abdruck der mütterlichen Hand, als Thetis ihn im Fluss Styx stählte, beim anderen ein Lindenblatt, das vom Helden unbemerkt beim Bad im Drachenblut auf seinem Rücken lag. Tödlich wurden die Löcher in der magischen Rüstung erst, als die Feinde davon erfuhren. Den einen traf ein Pfeil in die Ferse, den anderen Hagens Speer.

Kleine Ursache, letale Wirkung – genau das will der sicherheitsbewusste Linux-Admin vermeiden und stählt, härtet, patcht und testet sein System. Weil aber jedwede Software – ob frei oder nicht – immer Fehler hat, ist der Anwender hier auf die Power der Community angewiesen, aber auch auf die Arbeit der Distributoren und Sicherheitsexperten. Daher betreiben Suse und Red Hat hochqualifizierte Security Response Teams (SRT, [2], [3]), die verschiedene Informationsquellen überwachen und nach bekannt werdenden Sicherheitslücken durchforsten.

Informationsquellen

Mailinglisten, Datenbanken, Announcements von (anderen) Distributoren, Projekten, Entwicklern, aus Wikis und diversen Foren – auch denen, derer sich Hacker bedienen –, aber auch eigene Audits an Sourcecode, Binaries und proprietärer Software dienen ihnen als Informationsquelle.

Marcus Meißner, Security-Chef bei Suse: “Wir nutzen die CVE-Datenbanken (Common Vulnerabilities and Exposures, Allgemein bekannte Verwundbarkeiten und offene Schwachstellen, [4], d. Red.) von Mitre ([5], Abbildung 1) und NVD [6], die Open-Source-Security-Mailingliste [7] und dort auch die geschlossene Liste für Linux-Distributoren. Außerdem überwachen wir Adobe Flash und Reader, Mozilla- und Oracle(Java)-Feeds, führen eigene Sourcecode-Audits durch und scannen Changelogs nach verdächtigen Einträgen wie »buffer overflow fix« oder »XSS fixed« . Und es kommt vor, dass uns Entwickler selbst berichten. Heutzutage tauchen die CVEs meist zuerst auf der OSS-Security-Mailingliste auf, erst später in der Mitre-Datenbank.”

Abbildung 1: Eine typische CVE-Meldung mit Nummer, hier als Beispiel für einen Bug in Mozilla Firefox und Thunderbird.

Standardtool Bugzilla

Spätestens dann ticken die beiden großen Distributoren gleich: Sowohl Suse als auch Red Hat übernehmen die Meldung aus der CVE-Datenbank in die eigene DB, bei Red Hat unter [8] zu finden. Ein Verantwortlicher legt einen Bug in Bugzilla an: [9] und [10] zeigen beide als Beispiel das Mozilla-CVE 2012-1975, dem in Bugzilla (gemeinsam mit zahlreichen anderen CVEs) die ID 851910 zugewiesen ist. Jetzt prüfen die Entwickler, ob die Produkte, für die sie verantwortlich sind, betroffen sind und geben Ressourcen für die Lösung frei.

Normalerweise enthält der Bugreport bereits alle nötigen Informationen, die der Packager oder Maintainer benötigt, und in der Regel laufen jetzt auch schon automatische Methoden der Qualitätssicherung, Ressourcenplanung, Erfolgskontrolle und zur Messung der Reaktionszeit an.

Bei Suse übernimmt der jeweils zugewiesene Packager das Beheben des Problems, das SRT überwacht die Antwortzeit und hilft bei Schwierigkeiten. Anschließend gelangt das Paket ins Buildsystem (den IBS – Internal Build Service, ein Pendant des OBS), wo es nach einer initialen Abnahme eingecheckt wird. “War der Build erfolgreich, kommt die QA an die Reihe: Installiert es? Passen die Dependencies? Gelingt das Update? Außerdem kommen da auch generische Regressionstests zum Einsatz”, erläutert Marcus Meißner. “Erst danach, also wenn das QA-Team das finale Okay gegeben hat, gelangt das neue Paket auf die Update-Server, die Benachrichtigungen gehen per Mail raus.”

Red Hat greift dafür auf die Red Hat Security Advisories (RHSA) zurück, die die Firma nach Abschluss eines Fix publiziert – ebenfalls per Mail und Web. Abbildung 2 zeigt das gebaute Paket und die relevanten CVEs. Im oben angesprochenen Beispiel hat sich der Mozilla-Bug als kritisch in Firefox und Thunderbird erwiesen, deshalb gibt es zwei entsprechende RHSAs dazu: [11] und [12], siehe Abbildung 3. Wer sich für die Details interessiert, kann bei Red Hat auch online gezielt nach Schwachstellen und Fixes in der Paketdatenbank suchen [13].

Abbildung 2: Red Hat hat aus mehreren Fixes, die durch CVEs veranlasst waren, ein Update-Paket gebaut …

Abbildung 3: … und daraus wiederum zwei Advisories erstellt, weil der Bug sowohl Thunderbird als auch Firefox betraf.

Zertifikate

Haben die Mitarbeiter der Distributoren gut und vor allem nachweisbar gut gearbeitet, dann winkt als Beweis der Qualität eine Zertifizierung durch offizielle Regierungsstellen, beispielsweise dem Bundesamt für Sicherheit in der Informationstechnik BSI oder seinem amerikanischen Pendant NIAP (National Information Assurance Partnership).

Beide Enterprise-Distributionen erreichen die vierte Stufe der Common-Criteria-Zertifizierung EAL (Enterprise Evaluation Assurance Level, [14]) und dürfen sich mit dem Titel “Methodisch entwickelt, getestet und durchgesehen gemäß EAL 4+” schmücken. Red Hat liegt eine Nasenlänge vorne: Seit Oktober 2012 trägt auch RHEL 6 dieses Label.

Diese für Open-Source-Betriebssysteme ohne Modifikationen höchste mögliche Auszeichnung will Suse natürlich auch für seinen aktuellen Enterprise-Server erhalten. Für SLES 9 und 10 liegt EAL 4+ vor, bei SLES 11 warten die Nürnberger aber seit Monaten auf die Bestätigung. “Wir rechnen aber damit, dass das bald kommt”, hofft Meißner. Die EAL-Zertifikate interessieren überwiegend Behörden, aber auch Firmen im militärischen Bereich oder börsennotierte Konzerne mit Nachweispflicht.

Ein weiterer wichtiger Standard, für den regelmäßige, schnelle und koordinierte Updates, Patches und Bugfixes eine Rolle spielen, ist FIPS 140 (Federal Information Processing Standards, [15]). Er konzentriert sich eher auf Krypto-Software, und da kann Red Hat seit April 2011 auf sechs FIPS-140-2-Zertifikate verweisen, unter anderem für Kernel-Crypto, Open Swan, Open SSH und Open SSL. Suse strebt die Zertifizierung für Open SSL an.

Wer in Sachen nachweisbarer Sicherheit also höhere Ansprüche hat, scheint bei Red Hat richtig. Seit Anfang 2012 haben die roten Hüte es sogar geschafft, die Kombination aus RHEL, dem KVM-Hypervisor und IBM-Servern mit EAL4+-Zertifikaten versehen zu lassen. Viel mehr geht mit Open-Source-Mitteln nicht, zu streng sind die Vorgaben der höheren EAL-Level.