Im Wettlauf um die Sicherheit

Auch viele Augen sehen nicht immer alles, weswegen Open Source kein Allheilmittel ist

Der folgende Beitrag ist vor 2021 erschienen. Unsere Redaktion hat seither ein neues Leitbild und redaktionelle Standards. Weitere Informationen finden Sie hier.

Open Source ist auf dem besten Weg, als Allheilmittel angesehen zu werden. Der freie Zugang zum Quellcode von Programmen soll offene Standards, Transparenz und ein größeres Maß an Sicherheit garantieren. Zumindest im Bereich der Sicherheit ist es mit dem Offenlegen nicht getan.

Sicherheit im Internet", die gemeinsame Initiative von Innen- und Wirtschaftsministerium sowie dem Bundesamt für Sicherheit in der Informationstechnik, legt sich fest: "Open Source zeichnet sich dadurch aus, dass der Quellcode der Software bis ins letzte Detail offen liegt und damit überprüft werden kann. Damit wird die IT-Sicherheit deutlich erhöht."

Im letzten Satz spiegele sich ein wenig das Wunschdenken der Open Source-Gemeinde wider, meint dagegen Stefan Kelm, Mitarbeiter der Sicherheitsberatung Secorvo. "Die Sicherheit wird natürlich nicht dadurch erhöht, dass der Quellcode verfügbar ist. Die Offenlegung aller Quellen ist aber uneingeschränkte Voraussetzung für die Sicherheit von Systemen."

Der Einspruch ist begründet. Ausgerechnet das weitverbreitete Verschlüsselungsprogramm PGP machte im letzten halben Jahr durch zwei Fehler von sich reden. Im Mai entdeckte Germano Caronni einen Bug in der Version 5 der Unix-Variante. Caronni hatte den Code modifiziert und stieß dabei mehr oder minder zufällig auf einen Fehler in der Schlüsselgenerierung.

Im August präsentierte Ralf Senderek die Ergebnisse seiner Experimente mit der Möglichkeit, zusätzlich zum privaten Schlüssel weitere Dechiffrierungsschlüssel (ADK - Additional Decryption Keys) zu generieren. Das Feature wurde mit Version 5 von PGP eingeführt. Senderek dokumentierte, dass sich damit in einer Signatur zusätzliche, nicht von ihr abgedeckte Daten unterbringen lassen. PGP warnte bei der Benutzung entsprechend manipulierter Schlüssel nicht.

Die Herangehensweisen, mit denen die Fehler aufgedeckt wurden, können kaum unterschiedlicher sein. Dort Nachlesen im Quellcode des Programms, hier gezielte Experimente mit einer bestimmten Funktion. Gemeinsam ist beiden Fehlern jedoch die Zeit, die zwischen der Veröffentlichung des Codes und dem Aufspüren der Bugs verstrich: über zwei Jahre.

Der Hersteller, Network Associates, legt explizit die Quellen für PGP offen, um das so genannte Peer Review zu ermöglichen. Interessierte und Experten sollen die Chance erhalten, Fehler an der Quelle ausfindig zu machen. Allerdings handelt es sich bei PGP nicht um Open Source Software im eigentlichen Sinn. Der Code darf nur zu privaten Zwecken kompiliert werden, und eine veränderte Fassung weiterzugeben, untersagt die Lizenz ausdrücklich. Das mag für eine gewisse Zurückhaltung sorgen.

Doch auch im freien Gegenstück, GnuPG, wurde vor kurzem ein Fehler entdeckt, den das Programm von Anfang an mit sich herumtrug. GnuPG offenbarte dabei eine Schwäche im Umgang mit mehrfach signierten Texten. Werner Koch, der das GnuPG-Projekt leitet, sah sich dadurch veranlasst die griffige, von Eric Raymond stammende Formel - "Given enough eyeballs, all bugs are shallow" - in Frage zu stellen. Der darin verpackte Optimismus, Fehler ließen sich allein durch ausreichende Aufmerksamkeit bereinigen, sei im Bereich der Sicherheit fehl am Platz.

An der Voraussetzung: "Gegeben seien genügend Augen", hapert es vielfach. Thomas Roessler, der die Entwicklung eines Postprogramms für Unix namens "mutt", koordiniert, beschreibt die Zusammenarbeit: "In der letzten Zeit tragen vor allem zwei, drei Leute zur Entwicklung bei. Dann gibt es noch einige, die immer mal wieder Fehler beheben. Mindestens einer davon liest regelmäßig anderer Leute Patches gegen." Bei ausreichendem Vertrauen in den Autor kann aus dem Gegenlesen aber auch ein Überfliegen werden.

Etwas anders sieht es bei der Entwicklung von GnuPG aus. Da bei offiziellen GNU-Projekten das Copyright vertraglich der Free Software Foundation überschrieben wird, sind die Entwickler auch gehalten, sich an den "Coding-Standards" der Stiftung zu orientieren. Schon aus diesem Grund muss Koch Sourcecode von anderen genau ansehen. Inwieweit seine eigene Arbeit einer Prüfung unterzogen wird, kann er dagegen nur indirekt beurteilen: "Aus Kommentaren kann ich herauslesen, dass einige Leute recht gut mit dem Code vertraut sind."

Mit der Kenntnis des Codes scheint es nicht getan. Möglicherweise richtet sich das Augenmerk auch hier vor allem auf jene Aufgaben, für die ein Programm hauptsächlich gedacht ist. Dadurch entsteht Software, die sich beim überwiegenden Teil der Anwendungsfälle als robust und zuverlässig erweist. Trotzdem kann sie, wie im Fall GnuPG, in ihren exotischeren Funktionen mitunter Risiken bergen. Hinzu kommt, dass einschlägige Mailing-Listen, wie zum Beispiel Bugtraq, vor allem den quasi unsachgemäßen Gebrauch behandeln: Wie wird ein Programm dazu gebracht, dem Anwender administrative Privilegien zu verschaffen? Der Zweck, auf den hin es allseits getestet wurde, spielt dabei keine Rolle.

Wer im kommerziellen Bereich nach Offenlegung von Code als Qualitätssicherung fragt, stößt auf Skepsis. Bei der Berliner Firma HiSolutions, die Software für eine Public Key Infrastruktur entwickelt und vertreibt, meint der Geschäftsführer René Grosser: "Es bringt wenig, den Code in die Öffentlichkeit zu streuen." Eher erhalten Kunden, die explizit danach fragen, die Quellen. Dabei stoße man unter Umständen auch auf das für eine Beurteilung notwendige Knowhow. Intern setzt das Unternehmen darauf, die Programmteile von anderen Personen testen zu lassen, als denen, die sie geschrieben haben.

Im Bereich der Sicherheitsberatung spielen eigene Produkte seltener eine Rolle. Statt dessen werden die Produkte anderer Firmen empfohlen. Als Grundlage der Empfehlungen dienen einerseits Zertifikate, aber auch der gute Ruf einer Software, wenn sie etwa, wie die Verschlüsselungssoftware BestCrypt des Herstellers Jetico auch beim finnischen Militär zum Einsatz kommt. Andererseits werden Angriffsszenarien durchgespielt, aber zum Teil wird auch der Quelltext einer Prüfung unterzogen; steht der nicht zur Verfügung, dient Reverse Engineering schon mal als Ausweg. Indem so die Herangehensweise der Hacker zum Vorbild wird, entsteht ein Wettlauf.

Auf den haben sich auch die Linux-Distributoren eingelassen. Zu Olaf Kirchs Aufgabenbereich bei Caldera gehört auch das Auditing, die Sicherheitsüberprüfung, von Software. Im Vordergrund stehen dabei sicherheitsrelevante Pakete, die Eingang in Calderas Produkte finden sollen. Nach seiner Erfahrung beläuft sich der Anteil an immer wiederkehrenden Fehlern auf 80%. Sie lassen sich mit Blick auf bestimmte Funktionen im Quellcode ausmerzen.

Bei SuSE, berichtet Roman Drahtmüller, kümmern sich derzeit vier Mitarbeiter um pro-aktives Auditing. Auch sie flöhen den Quellcode der wichtigsten Programme durch und stellen sie auf die Probe. Daneben schult die Firma die Betreuer der Programmpakete in Sicherheitsfragen. Sie stehen in Verbindung zu den Programmierern und unterrichten sie über Schlupflöcher. "Zudem halten wir direkten Kontakt zu anderen Distributoren und Sicherheitsspezialisten", so Drahtmüller weiter.

Open Source kann in diesem Rennen einen Vorteil für sich verbuchen: Gefundene Fehler könnten bei ausreichend Sachverstand noch vor Ort behoben werden, ohne auf die Reaktion eines Herstellers warten zu müssen. Geschieht das rechtzeitig, kann zumindest das Ausnutzen bekannter Schwachstellen abgewehrt werden.

Doch Sicherheit ist keine Qualität, die sich automatisch mit dem Offenlegen von Programmquellen einstellt. Auch im Open Source-Bereich erweist sie sich vielerorts als ein Prozess. Der wird so lange erhalten bleiben, wie Kirchs Forderung nach sicherheitsbewusstem Programmieren ungehört verhallt.

Bemerkenswerterweise produzierten verschiedene Anläufe, wie das "Linux Security Auditing Project", dass immerhin eine betriebsame Mailing-Liste hervorgebracht hat, bislang nur Stückwerk. Es ist bisher nicht gelungen, ein stabiles Projekt ins Leben zu rufen, das - parallel zur Entwicklung - Software generell einer Überprüfung unterzieht. Wäre die Arbeit daran tatsächlich zu wenig glamourös, wie Werner Koch vermutet? Oder stimmt Germano Caronnis Annahme, es sei schlicht langweiliger, Code zu lesen, als ihn zu schreiben?

Dass es auch anders geht, zeigt ein anderes freies Betriebssystem: OpenBSD. "Drei Jahre ohne Loch in der Standard-Installation", prangt es auf der Webseite. Ohne Frage betreffen viele Mängel in den gängigen Zusatzpaketen auch OpenBSD. Aber es sticht dadurch deutlich hervor, dass ein Stamm von sechs bis acht Leuten regelmäßig den Quellcode der Standard-Programme überprüft. Dadurch wurden schon vor längerer Zeit die derzeit beliebten Stringformat-Bugs eliminiert. Nicht weil sie als ein Sicherheitsrisiko betrachtet worden wären, sondern weil es sich um Programmierfehler handelte.

"Sicherheit gibt es nicht zum Nulltarif", sagt Hubertus Soquat, Referent für IT-Sicherheit im BMWi, »si" verlangt stetige Arbeit." Es bleibt die Frage, ob sich der Aufwand nicht gezielt reduzieren ließe.