12.3
Software-Sicherheitslücken

Betriebssysteme wie Windows, UNIX und auch Anwendungsprogramme wie die Office-Produkte von Microsoft sind Programme, deren Quelltext aus Hunderttausenden von Zeilen besteht. Aus dem Quelltext werden die Programme durch Compiler erstellt. Die so entstandenen Programme können unerwünschte Funktionen haben, die ausgenutzt werden können, um weitreichende Zugriffsrechte einzurichten oder Schadfunktionen einzufügen. Die unerwünschten Funktionen können aus Designfehlern, Fehlern bei der Programmierung oder einer unzulänglichen Umsetzung in den ausführbaren Code resultieren. Daneben gibt es auch Standards, die Sicherheitslücken beinhalten. Ein Beispiel ist der Standard IEEE 802.11, mit dem u.a. die Verschlüsselung für Funk-LAN beschrieben ist (siehe Ziff. 12.1). Es kann aber auch ein Standard fehlerhaft implementiert sein. Dies galt z.B. für SSL (Secure Socket Layer)/TLS (Transport Layer Security), von dem in diesem Jahr mehrfach über Schwachstellen berichtet wurde. Sie betrafen aber immer die Implementierung.

Wenn Schwachstellen in Programmen bekannt werden, die auch von öffentlichen Stellen verwendet werden, stellt sich die Frage, wie damit umgegangen werden soll.

Diese Auffassung vertreten zum Beispiel die Betreiber von kostenlosen Informationsdiensten wie SecurityFocus mit der Mailingliste Bugtrac oder paketstorm. Sobald die Hersteller informiert wurden und Möglichkeiten zur Beseitigung gegeben waren, wird der Hinweis gemeinhin in das Internet gestellt. Die Hinweise sind aber in der Regel nicht so detailliert, dass ein Außenstehender einen Angriff darauf aufbauen kann. Nach einer Frist von etwa 30 Tagen folgen meist weitergehende Informationen, die es erlauben könnten, die Schwachstelle ausnutzen. Zum Teil werden sogar Programme bereitgestellt, um die Lücke auszunutzen (Exploits) oder, wie es die Anbieter begründen, um den eigenen Rechner auf die Lücke testen zu können. Der Nachteil dieses Vorgehens besteht darin, dass zum Teil sogar die Werkzeuge bereit gestellt werden, um Schwachstellen auszunutzen, obwohl noch keine Lösung bekannt ist, wie Angriffen begegnet werden kann.

Einige Informations-Anbieter haben eine Informationspolitik, die weniger weit geht. Im Jahr 2000 hat das CERT/CC (Computer Emergency Response Teams/Coordination Center; Carnegie-Mellon University) den bisherigen Ansatz geändert. Wenn bislang neue Sicherheitslücken bekannt wurden, wurde zusammen mit dem Hersteller und anderen Notfall-Teams versucht, die Lücken möglichst schnell und umfassend zu schließen. Sobald eine Lösung verfügbar war oder die Gesamtsituation ein Warten auf die Lösung verbot, wurden die notwendigen Informationen verteilt. Neuerdings veröffentlichen das CERT/CC und das DFN-CERT, das sich in seiner Informationspolitik an das CERT/CC anlehnt, bekannt gewordene Sicherheitslücken nach 45 Tagen, unabhängig davon, ob es Lösungen gibt. Allerdings werden keine Programme bereitgestellt, um die verwendete Software auf Lücken zu testen. Der Zeitraum kann unter Umständen verlängert werden, wenn komplexe Änderungen nötig sind (umfangreiche Untersuchung, Änderung an Kommunikationsprotokollen oder Kernkomponenten). Er kann auch verkürzt werden, wenn bereits Exploits existieren oder Angriffe bekannt werden.

Es gibt erste Hersteller, die gegen die Veröffentlichung von Sicherheitslücken ihrer Produkte vorgehen. Außerdem ist das Wissen um Sicherheitslücken eine Ware, die vermarktet werden kann. Befürchtungen, dass bisher kostenlose Informationsdienste eingestellt oder kostenpflichtig werden könnten, wurden laut, als ein Informationsdienst von einem großen Anbieter von Sicherheitssoftware aufgekauft worden war.

Diesen Ansatz favorisieren die meisten Hersteller. Es vergeht aber oft viel Zeit zwischen dem Zeitpunkt, zu dem in "interessierten Kreisen" eine Sicherheitslücke bekannt wird, und dem Zeitpunkt, zu dem der Hersteller eine Lösung anbietet. So wurden beispielsweise zum Internet Explorer der Fa. Microsoft am 2. Oktober 2002 zwanzig noch nicht beseitigte Lücken genannt, deren erste Veröffentlichung teilweise aus dem ersten Halbjahr 2002 und in einem Fall aus 2001 stammt. Wenn nach diesem Modell vorgegangen wird, profitieren davon besonders Personen, denen eine Schwachstelle bekannt ist. Gerade im Internet gibt es Gruppen, die auch ohne allgemein zugängliche Informationsdienste über die Existenz von Schwachstellen kommunizieren. Der Betreiber eines IT-Systems kann sich dagegen nur unvollständig oder mit viel Aufwand wappnen. Die Informationspolitik wiegt die Anwender in trügerischer Sicherheit, obwohl Angreifer eventuell mit wenig Aufwand Schaden verursachen können.

Aus meiner Sicht sind unabhängige Informationsanbieter unverzichtbar, die über Sicherheitslücken zeitnah informieren. Der Service sollte kostenlos sein, damit möglichst viele Interessenten erreicht werden. Die grundsätzliche Vorgehensweise der CERT, die keine Exploits veröffentlichen, halte ich für richtig.

Eine Übersicht von Mängeln in Betriebssystemen und Standardprogrammen lässt sich nicht geben, da eine solche Übersicht nie umfassend und aktuell wäre. Da SSL/TLS als Standard für eine Kommunikation im Internet genutzt wird - z.B. durch die KIV Hessen -, möchte ich auf Mitteilungen der letzten Monate eingehen, nach denen SSL unsicher sei.

Im Internet gab es in den bekannten Informationsbörsen Nachrichten über Probleme mit Implementierungen des SSL-Protokolls in einigen Programmen.

Die genannten Probleme betreffen jeweils einzelne Implementierungen und nicht alle Produkte, die SSL unterstützen oder das Protokoll SSL selbst. Auch sind weder einzelne Schlüssel - ausreichend lange Schlüssel vorausgesetzt (mittlerweile sind 128 Bit für den symmetrischen und 1024 Bit für den RSA-Algorithmus Stand der Technik) - noch das Verfahren insgesamt gebrochen worden. Selbstverständlich müssen Patchs immer unverzüglich eingespielt werden, um die gefundenen Lücken zu schließen. Zusammenfassend ist festzuhalten, dass SSL als Standard keineswegs zu unsicher ist und nicht mehr benutzt werden sollte.

Jeder Administrator in Behörden oder Unternehmen muss sich über mögliche Lücken der von ihm betreuten Systeme informieren. Diese Aufgabe darf nicht nur im Geschäftsverteilungsplan genannt sein. Es muss auch die Zeit für Recherchen und Abhilfemaßnahmen zur Verfügung stehen. Um einen Überblick zu bekommen, reicht es nicht, die Informationsseiten der Hersteller zu durchsuchen. Die unabhängigen Informationsanbieter, Anbieter von Sicherheitslösungen und die CERT mit ihren Mailinglisten sind unverzichtbare Quellen. Hinweise, wie eine Lücke notdürftig geschlossen werden kann, gibt es eventuell bei verschiedenen Informationsanbietern, aber Programmupdates kann man in aller Regel nur vom Hersteller erhalten.

Als technischer Laie erhält man bei vielen Informationsanbietern keine brauchbare Hilfe, da die Beschreibungen Hintergrundwissen voraussetzen. Hier bleibt in aller Regel nur die Möglichkeit, sich über Zeitschriften oder den Hersteller zu informieren. Man sollte Programmupdates der Hersteller möglichst umgehend einspielen, wenn die Lücken im eigenen Umfeld eine Rolle spielen.

zurück, weiter, Inhalt 31.TB, Sachwortverzeichnis zum 31.TB