Crypto-Gram 15. November 2001

Crypto-Gram Newsletter 15. November 2001

von Bruce Schneier
Gründer und CTO
Counterpane Internet Security, Inc.
schneier@counterpane.com
<http://www.counterpane.com/>

Ein kostenloser monatlicher Newsletter mit Zusammenfassungen, Analysen, Einsichten und Kommentaren über Computersicherheit und Kryptographie.

Ältere Ausgaben und die Möglichkeit des Abonnements stehen hier zur Verfügung:
<http://www.schneier.com/crypto-gram.html>

Deutsche Übersetzung von Holger Hasselbach, galad.com
mit freundlicher Erlaubnis der Counterpane Internet Security, Inc.
h.hasselbach@galad.com
<http://www.galad.com/>

Dies ist keine vollständige Übersetzung des Newsletters. Nicht übersetzte Teile enthalten einen Link auf das Original.
Stand: 07.12.2001

Alle Übersetzungen stehen hier zur Verfügung:
<http://archiv.galad.com/cg/cg.htm>

In dieser Ausgabe:

Full Disclosure - Vollständige Offenlegung
Crypto-Gram Reprints
News
Counterpane Internet Security News
GOVNET
Sicherheitslücke in Password Safe
Microsoft über Windows XP
Leserkommentare

Full Disclosure - Vollständige Offenlegung

Microsoft ist in der Beschränkung des freien Flusses von Computer-Sicherheitslücken federführend. Letzten Monat hat Scott Culp, Chef des Microsoft Security Response Centers, ein Essay veröffentlicht, in dem er die aktuelle Praxis der Veröffentlichung von Sicherheitslücken als "Informations-Anarchie" beschrieben hat. Er behauptete, dass wir alle sehr viel sicherer wären, wenn die Sicherheitsexperten die Details über Sicherheitslücken für sich behielten und Hacker nicht mehr mit Angriffswerkzeugen bewaffnen würden. Letzte Woche kündigte er auf Microsofts Trusted Computing Forum eine neue Vereinigung an, um diese Ideen in die Praxis umzusetzen.

Dies ist die klassische Auseinandersetzung "Geheimhaltung von Fehlern vs. Full Disclosure - Vollständige Offenlegung". Ich habe schon früher in Crypto-Gram darüber geschrieben; ebenso wie andere darüber geschrieben haben. Es ist eine komplizierte Streitfrage mit subtilen Implikationen über alle Bereiche der Computersicherheit, und sie ist eine weitere Diskussion wert.

Window of Exposure - Das Fenster der Gefährdung

Ich habe den Begriff des "Window of Exposure - Fenster der Gefährdung" geprägt, um die zeitliche Evolution einer Sicherheitslücke zu erläutern. Eine Sicherheitslücke ist ein Bug; ein Programmierfehler eines Programmierers, der während der Produktentwicklung gemacht und in der Testphase nicht entdeckt wurde. Sie ist eine Schwachstelle, die von jemandem zum Einbruch in den Computer oder zu etwas normalerweise Verbotenem missbraucht werden kann.

Angenommen, ein Produkt weist eine Sicherheitslücke auf und niemand hat davon Kenntnis. Dabei besteht wenig Gefahr, weil niemand die Sicherheitslücke auszunutzen weiß. Die Sicherheitslücke kann für eine kurze Zeit unentdeckt bleiben -- Sicherheitslücken in Windows XP wurden vor der Veröffentlichung des Produkts entdeckt -- oder für Jahre. Schließlich entdeckt jemand die Sicherheitslücke. Vielleicht ist es einer von den Guten, der den Entwickler benachrichtigt. Vielleicht ist es einer von den Bösen, der die Lücke zum Einbrechen in Systeme nutzt. Vielleicht ist es jemand, der nichts weitererzählt, und ein paar Monate später entdeckt sie jemand anders. Auf jeden Fall nimmt die Gefahr zu, sobald jemand von der Sicherheitslücke weiß.

Letztendlich macht die Neuigkeit der Sicherheitslücke die Runde. Eventuell verbreitet sie sich in der Sicherheits-Community. Eventuell verbreitet sie sich im Hacker-Untergrund. Die Gefahr nimmt weiter zu, je mehr Leute von der Lücke erfahren. An irgend einem Punkt wird die Sicherheitslücke bekannt gegeben. Möglicherweise wird sie auf Bugtraq oder einer anderen sicherheitsbezogenen Website bekannt gegeben. Möglicherweise wird sie vom Sicherheitsexperten in einer Presseerklärung bekannt gegeben, oder von CERT, oder vom Softwareentwickler. Möglicherweise wird sie in einem Hacker-Forum bekannt gegeben. Aber sobald sie bekannt gegeben ist, nimmt die Gefahr sogar noch weiter zu, weil nun mehr Leute über sie Bescheid wissen.

Dann schreibt jemand einen Exploit: ein automatisches Werkzeug zur Ausnutzung der Sicherheitslücke. Dies ist ein Wendepunkt, und einer ohne eine Entsprechung in der realen Welt, aus zwei Gründen. Erstens hat Software die Eigenschaft, die Fertigkeit von der Fähigkeit zu trennen. Sobald das Werkzeug geschrieben ist, kann jeder die Sicherheitslücke unabhängig von seiner Fertigkeit und seinem Verständnis ausnutzen. Zweitens kann dieses Werkzeug ohne Kosten weit verteilt werden und auf diese Weise jedem der es möchte die Fähigkeit geben. Hier kommen "Script Kiddies" ins Spiel: Leute, die automatische Angriffswerkzeuge zum Einbruch in Systeme benutzen. Sobald ein Werkzeug geschrieben ist, nimmt die Gefahr um mehrere Größenordnungen zu.

Dann bringt der Softwareentwickler einen Patch heraus. Die Gefahr sinkt, aber nicht so weit wie wir es uns gerne denken. Eine große Zahl Computer im Internet haben ihre Patches nicht auf dem aktuellen Stand; es gibt viele Beispiele von Systemen, in die unter Ausnutzung von Sicherheitslücken eingebrochen wurde, die eigentlich hätten gepatcht sein sollen. Ich gebe nicht den Administratoren die Schuld dafür; es gibt einfach zu viele Patches, und viele von ihnen sind schlampig geschrieben und schlecht getestet. Obwohl also die Gefahr abnimmt, wird sie niemals zurück auf null gehen.

Dies kann man sich als Graph vorstellen, in dem die Gefahr gegen die Zeit aufgetragen wird. Das Window of Exposure entspricht der Fläche unter dem Graphen. Ziel ist es, diese Fläche so klein wie möglich zu machen. Mit anderen Worten, wir wollen dass über den Lebenszyklus der Software und der jeweiligen Sicherheitslücke so wenig Gefahr wie möglich besteht. Die Befürworter der Geheimhaltung von Fehlern und die Befürworter des Full Disclosure haben ganz einfach unterschiedliche Ideen darüber, wie dies erreicht werden kann.

Geschichte des Full Disclosure

In den frühen Jahren der Computer und der Netzwerke war die Geheimhaltung von Fehlern die Norm. Wenn Benutzer und Forscher in einem Softwareprodukt Sicherheitslücken fanden, würden sie stillschweigend den Hersteller alarmieren. In der Theorie würde der Hersteller dann die Sicherheitslücke beseitigen. Nach der Gründung von CERT 1988 wurde es zu einem Clearinghaus für Sicherheitslücken. Die Leute würden neu entdeckte Lücken an das CERT schicken. CERT würde sie überprüfen, den Hersteller alarmieren und, sobald eine Lösung zur Verfügung steht, die Details (und die Lösung) publizieren.

Das Problem mit diesem System besteht darin, dass die Hersteller keinerlei Motivation für die Beseitigung der Sicherheitslücken hatten. CERT würde nichts publizieren, bis die Lösung verfügbar war, also gab es keine Dringlichkeit. Die Geheimhaltung der Lücken war einfacher. Es gab Fälle, in denen die Hersteller den Forschern drohten, falls diese ihre Erkenntnisse publik machten, und Schmutzkampagnen gegen Forscher, die die Existenz von Sicherheitslücken bekannt gaben (sogar wenn sie Details ausließen). Und so verblieben viele Lücken für Jahre ohne Lösung.

Die Bewegung des Full Disclosure wurde aus Frustration über diesen Prozess geboren. Sobald eine Sicherheitslücke publiziert ist, gibt der öffentliche Druck dem Hersteller einen starken Ansporn, das Problem schnell zu beseitigen. Meist hat dies funktioniert. Heutzutage publizieren viele Forscher von ihnen gefundene Sicherheitslücken über Mailinglisten wie Bugtraq. Die Presse schreibt in Computermagazinen über die Lücken. Die Hersteller bemühen sich, diese Lücken nach ihrer Veröffentlichung schnellstmöglich zu patchen, damit sie ihre eigenen Pressemitteilungen über die schnelle und gründliche Beseitigung schreiben können. Die Bewegung des Full Disclosure verbessert die Sicherheit im Internet.

Zur selben Zeit benutzen Hacker diese Mailinglisten, um von Sicherheitslücken zu erfahren und Exploits zu schreiben. Manchmal schreiben die Forscher selbst demonstrative Exploits. Manchmal machen es andere. Diese Exploits werden zum Einbruch in unsichere Computer und Netzwerke benutzt, wodurch sie die Sicherheit im Internet stark reduzieren. Scott Culp führt in seinem Essay Code Red, Li0n, Sadmind, Ramen und Nimda als Beispiele für böswilligen Code an, der geschrieben wurde nachdem Forscher die Funktionsweise von einzelnen Sicherheitslücken demonstrierten.

Die Gegner der Full Disclosure-Bewegung argumentieren, dass die Veröffentlichung von Sicherheitslücken mehr Schaden als Gutes anrichtet, weil dadurch die kriminellen Hacker mit Werkzeugen bewaffnet werden, mit denen sie in Systeme einbrechen können. Sicherheit wird weitaus besser gewährleistet, ist ihre Entgegnung, wenn die exakten Details der Lücken geheim bleiben.

Die Befürworter des Full Disclosure entgegnen, dass dies auf der Annahme basiert, dass die Forscher die die Sicherheitslücken publizieren immer die ersten sind, die sie auch entdecken, was ganz einfach nicht stimmt. Manchmal waren Lücken den Angreifern bereits Monate oder Jahre bekannt oder zirkulierten still und leise im Hacker-Untergrund, bevor der Hersteller überhaupt davon erfuhr. Je schneller die Lücke veröffentlicht und beseitigt wird, desto besser ist dies für jeden, sagen sie. Die Rückkehr zur Geheimhaltung von Fehlern würde lediglich die Verleugnung durch den Hersteller und seine Untätigkeit zurück bringen.

Die Auseinandersetzung in aller Kürze: Ist der Nutzen der Veröffentlichung eines Angriffs die gesteigerte Bedrohung durch den Feind wert, der davon erfährt? Sollten wir das Window of Exposure verkleinern, indem wir versuchen das Wissen über die Sicherheitslücke einzuschränken, oder indem wir Sicherheitslücken veröffentlichen, um dadurch die Hersteller zur schnellstmöglichen Beseitung zu zwingen?

Was wir in den letzten ca. acht Jahren gelernt haben ist, dass Full Disclosure sehr viel mehr hilft als schadet. Seit Full Disclosure die Norm wurde, hat sich die Computerindustrie von einer Gruppe aus Unternehmen, die Sicherheit ignoriert und Sicherheitslücken verharmlost hat, in eine verwandelt, die Sicherheitslücken so schnell wie möglich beseitigt. Einige wenige Unternehmen gehen sogar noch weiter und nehmen Sicherheit ernst genug, um die Entwicklung von Qualitätssoftware von Anfang an anzustreben: Die Sicherheitslücken sollen vor dem Release des Produkts beseitigt werden. Und sehr viel weniger Probleme zeigen sich zuerst im Hacker-Untergrund, wenn Leute absolut ohne Warnung angegriffen werden. Ursprünglich waren Informationen über Sicherheitslücken nur einigen Auserwählten zugänglich: Sicherheitsexperten und Hackern, die in ihrer jeweiligen Community ausreichend vernetzt waren. Jetzt sind sie für jeden zugänglich.

Diese Demokratisierung ist wichtig. Wenn eine bekannte Lücke existiert und Sie nichts darüber wissen, dann treffen Sie ihre Sicherheits-relevanten Entscheidungen mit ungenügenden Daten. Letztendlich wird es herauskommen -- das Window of Exposure wird wachsen -- aber Sie haben keine Kontrolle oder Kenntnisse über das Wann und Wie. Sie können nur hoffen, dass die Bösen nichts herausfinden bevor die Guten das Problem beseitigt haben. Full Disclosure bedeutet, dass jeder die Informationen zur selben Zeit erhält und jeder entsprechend handeln kann.

Und es sind detaillierte Informationen erforderlich. Wenn ein Forscher lediglich vage Äußerungen über die Sicherheitslücke veröffentlicht, kann der Hersteller behaupten, dass diese nicht wirklich existiert. Wenn der Forscher wissenschaftliche Details ohne Beispielcode veröffentlicht, kann der Hersteller behaupten, dass dies nur theroretisch ist. Der einzige Weg zur Erlangung der Aufmerksamkeit der Hersteller ist die Veröffentlichung von Details: Sowohl in menschen- als auch in maschinenlesbarer Form. (Microsoft ist beider Praktiken schuldig, indem sie über ihre PR-Maschinerie Sicherheitslücken verleugnet und verharmlost haben, bis sie durch tatsächlichen Code demonstriert wurden.) Und Code zur Demonstration ist die einzige Möglichkeit zur Überprüfung, ob der Sicherheitspatch des Herstellers wirklich die Sicherheitslücken gepatched hat.

Dieser freie Fluss der Informationen, sowohl der Beschreibung als auch des Proof-of-concept-Codes, ist ebenso für die Sicherheitsforschung unerlässlich. Forschung und Entwicklung haben im Bereich der Computersicherheit im letzten Jahrzehnt eine Blüte erlebt, und viel davon kann der Full Disclosure-Bewegung zugeschrieben werden. Die Möglichkeit der Veröffentlichung von Forschungsergebnissen -- sowohl gute wie schlechte -- führt zu besserer Sicherheit für jeden. Ohne Veröffentlichung kann in der Sicherheits-Community nicht von den Fehlern der anderen gelernt werden. Jeder müßte mit Scheuklappen arbeiten und dieselben Fehler wieder und wieder machen. Full Disclosure ist unverzichtbar, wenn wir weiterhin die Sicherheit unserer Computer und Netzwerke verbessern wollen.

Beispiel für die Geheimhaltung von Fehlern

Die Probleme mit der Geheimhaltung von Fehlern werden in der Digital Rights Management-Industrie sichtbar. Mit dem DMCA ist das Paradigma der Geheimhaltung von Fehlern in die Gesetze eingetragen worden; in den meisten Fällen ist die Veröffentlichung von Sicherheitslücken oder automatischen Hackertools gegen Kopierschutz-Mechanismen illegal. Forscher werden drangsaliert und es wird Druck auf sie ausgeübt, damit sie ihre Arbeiten nicht weitergeben. Sicherheitslücken werden geheim gehalten. Und das Ergebnis ist eine Unmenge von unsicheren Systemen, deren Eigentümer hinter dem Gesetz ein Getöse fabrizieren, immer mit der Hoffnung, dass niemand herausfindet wie schlecht die Systeme wirklich sind.

Das Ergebnis ist, dass Anwender keine vernünftigen Entscheidungen zur Sicherheit treffen können. Hier ist ein Beispiel: Vor einigen Monaten fand der Sicherheitsexperte Niels Ferguson einen Sicherheitsmangel in Intels HDCP Digital Video Encryption System, hielt aber die Veröffentlichung aus Angst vor einer Anklage unter dem DMCA zurück. Intels Reaktion war eine Erinnerung an die Zeit vor dem Full Disclosure: Sie wiesen den Crack als "theoretisch" zurück und behaupteten, dass das System weiterhin sicher sei. Stellen Sie sich vor, Sie würden über den Kauf von Intels System nachdenken. Was machen Sie? Sie haben keine wirkliche Information, also müssen Sie entweder Ferguson oder Intel vertrauen.

Ein weiteres Beispiel: Vor einigen Wochen kam ein Linux Kernel ohne die üblichen detaillierten Informationen über die Sicherheit des Betriebssystems heraus. Die Entwickler führten Angst vor dem DMCA als Grund an, warum diese Details zurück gehalten wurden. Stellen Sie sich vor, sie bewerten Betriebssysteme: Fühlen Sie sich mehr oder weniger überzeugt von der Sicherheit der Linux Kernel-Version 2.2, jetzt da Sie keine Details mehr haben?

Full Disclosure und Verantwortung

Scott Culp trifft einen Punkt, wenn er über Verantwortung spricht. (Natürlich vermeidet er "mea Culpa.") Das Ziel ist hier die Verbesserung der Sicherheit, nicht die Bewaffnung von Leuten, die in Computer und Netzwerke einbrechen. Automatische Hackertools mit einfachen point-and-click-Interfaces, einsatzfertig für Script Kiddies, verursachen in Organisationen und ihren Netzwerken eine Menge Schaden. Es gibt so etwas wie verantwortliche und unverantwortliche Offenlegung. Die Unterscheidung ist nicht immer einfach zu treffen, aber ich habe einige Richtlinien.

Erstens, ich stelle mich gegen Angriffe, die hauptsächlich Angst säen sollen. Die Veröffentlichung von Sicherheitslücken, für die es keine wirklichen Beweise gibt, ist schlecht. Die Veröffentlichung von Sicherheitslücken, die mehr Rauch als Feuer sind, ist schlecht. Die Veröffentlichung von Sicherheitslücken in kritischen Systemen, die nicht einfach beseitigt werden können und deren Anwendung ernsten Schaden verursachen kann (z.B. in Flugleitsystemen), ist schlecht.

Zweitens, ich halte viel davon, den Hersteller im Voraus zu benachrichtigen. CERT hat dies bis ins Extrem getan und dem Hersteller manchmal Jahre für die Beseitigung des Problems gegeben. Ich würde es gerne sehen, wenn der Forscher dem Hersteller mitteilt, dass er die Sicherheitslücke in einigen Wochen publizieren wird, und dieses Versprechen dann auch einhält. Zur Zeit gibt CERT den Herstellern 45 Tage, legt die Lücken aber sofort für bezahlende Abonnenten offen. Microsoft schlägt eine Geheimhaltungsdauer von 30 Tagen vor. Während dies in der Theorie eine gute Idee ist, hat der Aufbau einer speziellen Insidergruppe von "Eingeweihten" ihre eigene Problemsammlung.

Drittens, ich stimme mit Culp darin überein, dass es unverantwortlich und möglicherweise kriminell ist, einfach zu benutzende Exploits zu verteilen. Reverse Engineering von Sicherheitssystemen, die Entdeckung von Sicherheitslücken, das Schreiben von Forschungsarbeiten darüber und sogar die Entwicklung von Demonstrationscode begünstigt die Forschung; es macht uns im Design von sicheren Systemen geschickter. Die Verteilung von Exploits macht uns lediglich angreifbarer. Ich würde gerne die Leute, die z.B. Virus Creation Kits schreiben, in die Hände bekommen. Sie hätten eine Menge zu verantworten.

Dies ist nicht scharf umrissen: Es gibt Tools, die sowohl nützlich als auch schädlich sind, und manchmal ist der Unterschied lediglich Marketing. Dan Farmer wurde für die Entwicklung von SATAN verunglimpft; heute sind Tools zur Bewertung von Sicherheitslücken entwicklungsfähige Produkte zur Sicherheits-Administration. Tools zur Remote-Administration sehen Back Orifice sehr ähnlich (obwohl sie nicht über so viele Features verfügen). L0phtCrack ist ein Hackertool zum Knacken von schwachen Passworten als Einleitung eines Angriffs, aber LC 3.0 wird als Tool zur Netzwerk-Administration zum Test auf schwache Passworte verkauft. Und das Programm, für dessen Entwicklung Dmitry Sklyarov verhaftet wurde, hat legitime Einsatzmöglichkeiten. Tatsächlich bieten die meisten Tools sowohl gute als auch schlechte Anwendungen, und im Zweifelsfall halte ich mehr davon, die Informationen den Leuten in die Hände zu geben, die sie brauchen, auch wenn die Bösen sie dadurch ebenfalls bekommen.

Eine Sache, auf die man achtgeben sollte, ist die Zielsetzung des Forschers. Die Veröffentlichung einer Sicherheitslücke ist oftmals ein Reklamespiel; der Forscher versucht, durch erfolgreiches Aufbauschen seiner Beute seinen eigenen Namen in die Zeitung zu bekommen. Der Publizierer hat oftmals seine eigene Zielsetzung: er ist ein Sicherheitsberater oder ein Angestellter einer Firma, die Sicherheitsprodukte oder -dienstleistungen anbietet. Ich finde die Firmen langsam etwas ermüdend, die Sicherheitslücken zu dem Zweck veröffentlichen, ihre eigenen Produkte und Dienstleistungen voranzutreiben. Obwohl, natürlich, ein nicht-altruistisches Motiv nicht bedeutet, dass die Information schlecht ist.

Ich mag die Einteilung "sei Teil der Lösung, nicht Teil des Problems". Die Erforschung der Sicherheit ist Teil der Lösung. Die Hersteller zur Beseitigung des Problems zu überreden ist Teil der Lösung. Das Säen von Angst ist Teil des Problems. Das Aushändigen von Angriffstools an ahnungslose Jugendliche ist Teil des Problems.

Die Unvermeidbarkeit von Sicherheitslücken

Nichts hiervon würde eine Streitfrage sein, wenn Software von Anfang an richtig entwickelt würde. Eine Sicherheitslücke ist ein Programmierfehler: entweder ein altbekannter Fehler wie ein Buffer Overflow, der hätte gefunden und vermieden werden sollen, oder eine Schwachstelle, verursacht durch mangelndes Verständnis der Interaktionen in einem komplexen Teil des Codes. Wenn es keine Sicherheitslücken gäbe, würde es kein Problem geben. An erster Stelle verursacht schlechte Softwarequalität diesen Schlamassel.

Während dies zutrifft -- Softwarehersteller produzieren einheitlich minderwertige Software -- bedeutet die bloße Komplexität der modernen Software und der Netzwerke, dass Sicherheitslücken, sehr viele Sicherheitslücken, unvermeidbar sind. Sie existieren in jedem größeren Softwarepaket. Jedes mal wenn Microsoft ein neues Betriebssystem veröffentlicht, triumphieren sie darüber, wie umfangreich das Testen war und wie sicher es ist, und jedes mal enthält es mehr Sicherheitslücken wie das vorhergehende Betriebssystem. Ich glaube nicht, dass sich dieser Trend irgendwann demnächst umkehren wird.

Die Hersteller nehmen Sicherheit nicht ernst, weil es für sie keinen marktbedingten Anreiz gibt und keine nachteiligen Effekte, wenn sie es nicht tun. Ich habe lange argumentiert, dass Softwarehersteller nicht von Produkthaftungs-Gesetzen freigestellt werden sollten, die den Rest des Marktes regeln. Wenn dies passiert, werden die Hersteller mehr als nur Lippenbekenntnisse zu Sicherheitslücken beisteuern: Sie werden sie so schnell wie möglich beseitigen. Aber bis dahin ist Full Disclosure unser einziger Weg, die Hersteller zu einem verantwortungsvolleren Handeln zu motivieren.

Microsofts Motive hinter der Förderung der Geheimhaltung von Fehlern sind offensichtlich: Es ist wesentlich einfacher, sicherheitsrelevante Informationen zu zermalmen als die Probleme zu lösen oder die Produkte von Anfang an sicher zu designen. Microsofts stetiger Strom an öffentlichen Sicherheitslücken hat viele Leute dazu gebracht, die Sicherheit ihrer zukünftigen Produkte anzuzweifeln. Und mit Analysten wie Gartner, die den Leuten raten, auf den Microsoft IIS aufgrund seiner gesamten Unsicherheiten zu verzichten, würde es für das Geschäft gut sein, den Kunden weniger Informationen über die Sicherheit ihrer Produkte zu geben.

Die Geheimhaltung von Fehlern ist nur dann eine machbare Lösung, wenn Softwarehersteller Anhänger der Prizipien des Qualitätsmanagements von W. Edward Deming sind. Je länger ein Bug ohne Beseitigung verbleibt, desto größer ist er als Problem. Und weil die Zahl von Systemen am Internet ständig anwächst gilt: Je länger eine Sicherheitslücke unbeseitigt verbleibt, desto größer ist das Window of Exposure. Wenn Firmen dies glauben und entsprechend handeln, dann gibt es damit ein schlagkräftiges Argument für die Geheimhaltung.

Jedoch zeigt die Geschichte, dass dies nicht der Fall ist. Lesen Sie Scott Culps Essay: Er sagte nicht: "Hey Jungs, wenn ihr einen Bug habt, schickt ihn zu mir, und ich stelle sicher, dass er pronto beseitigt wird." Stattdessen hatte er gegen die Veröffentlichung von Sicherheitslücken gewettert und die Forscher dazu angehalten, Details unter ihren Hüten zu behalten. Ansonsten, drohte er, "werden die Hersteller keine Wahl haben als andere Wege zum Schutz ihrer Kunden zu finden," was immer das heißen mag. Das ist die Einstellung, die Full Disclosure zum einzigen machbaren Weg zur Reduktion des Fensters der Verwundbarkeit macht.

In seinem Essay vergleicht Culp die Veröffentlichung von Sicherheitslücken mit dem Ruf "Feuer" in einem gefüllten Kino. Was er vergißt ist, dass dort wirklich ein Feuer ist; die Sicherheitslücken existieren trotzdem. Denjenigen zu beschuldigen, der die Lücke offenlegte, ist wie denjenigen einzusperren, der als erster die Flammen sah. Offenlegung erzeugt keine Sicherheitslücken; Programmierer erzeugen sie, und sie verbleiben bis andere Programmierer sie finden und beseitigen. Jeder macht Fehler; es sind in dem Sinn natürliche Ereignisse, dass sie unvermeidlich passieren. Aber das ist keine Entschuldigung dafür, ihre Verursachung durch Kräfte außerhalb unserer Kontrolle und ihre Entschärfung durch Drumherumreden vorzutäuschen.

Scott Culps Essay:
<http://www.microsoft.com/technet/columns/security/noarch.asp>

F&A mit Culp:
<http://news.cnet.com/news/0-1014-201-7819204-0.html>

Newsartikel über Culp:
<http://www.theregister.co.uk/content/55/22332.html>
<http://news.cnet.com/news/0-1003-200-7560391.html?tag=mn_hd>
<http://cgi.zdnet.com/slink?153618:8469234>

Microsofts Sicherheitsvorstoß:
<http://www.securityfocus.com/news/281>
<http://213.40.196.62/media/670.ppt>
<http://www.theregister.co.uk/content/4/22614.html>
<http://www.theregister.co.uk/content/4/22740.html>

Mein ursprüngliches Essay über das Window of Exposure:
<http://www.schneier.com/crypto-gram-0009.html#1>

Meine früheren Essays über Full Disclosure:
<http://www.schneier.com/crypto-gram-0001.html#KeyFindingAttacksandPublicityAttacks>
<http://www.schneier.com/crypto-gram-0002.html#PublicizingVulnerabilities>
Bitte beachten, dass die nCipher-Anekdote nicht stimmt. Details gibt es hier:
<http://www.schneier.com/crypto-gram-0104.html#2>

Andere Kommentare:
<http://www.securityfocus.com/news/270>
<http://web.ranum.com/usenix/ranum_5_temp.pdf>
<http://www.osopinion.com/perl/story/13871.html>
<http://www.synthesis.net/tech/fulldisclosure/>
<http://www.osopinion.com/perl/story/14401.html>
<http://www.net-security.org/text/articles/disclosure.shtml>

Dank an Tina Bird, Jon Callas, Scott Culp, Greg Guerin, Elias Levy, Jeff Moss, Eric Raymond und Elizabeth Zwicky für das Lesen und die Kommentierung dieses Essays.

Crypto-Gram Reprints

Why Digital Signatures are Not Signatures
<http://www.schneier.com/crypto-gram-0011.html#1>

Programming Satan's Computer: Why Computers are Insecure
<http://www.schneier.com/crypto-gram-9911.html#WhyComputersareInsecure>

Elliptic-Curve Public-Key Cryptography
<http://www.schneier.com/crypto-gram-9911.html#EllipticCurvePublic-KeyCryptography>

The Future of Fraud: Three reasons why electronic commerce is different
<http://www.schneier.com/crypto-gram-9811.html#commerce>

Software Copy Protection: Why copy protection does not work
<http://www.schneier.com/crypto-gram-9811.html#copy>

News

Senator Gregg wird doch keine Gesetzesvorlage einbringen, die die Regierung zum Zugriff auf Verschlüsselung bevollmächtigt:
<http://www.wired.com/news/conflict/0,2100,47635,00.html>

Das FBI erweitert seine Bestrebungen, den Internetverkehr abzuhören:
<http://www.interactiveweek.com/article/0,3658,s%3D605%26a%3D16678,00.asp>

Nur für den Fall, dass irgendjemand meine an Hysterie grenzenden Äußerungen über die Unterhaltungsindustrie und ihre Bereitschaft anzweifelt, zum Erreichen ihrer Ziele die Computerindustrie zu zerstören... Letzten Monat versuchte die RIAA, einen Nachtrag in das Anti-Terror-Gesetzespaket zu schmuggeln, der ihr das Recht geben würde, sich auf der Suche nach unauthorisiertem, copyrightgeschütztem Material in Computer zu hacken. Ich bin über diesen Versuch empört, Leute, die unauthorisierte Musikkopien erstellen, mit Leuten gleichzusetzen, die Passagierflugzeuge in Wolkenkratzer fliegen.
<http://www.wired.com/news/conflict/0,2100,47552-2,00.html>
<http://www.zdnet.com/zdnn/stories/comment/0,5859,2818346,00.html>
Und sie erwägen außerdem den Einsatz von Denial-of-Service-Angriffen, um File-Sharing-Server still zu legen.
<http://www.theregister.co.uk/content/55/22327.html>
Und die SSSCA-Saga geht weiter:
<http://www.newsforge.com/article.pl?sid=01/10/19/1546246>
Es ist nicht viel über das Gesetzespaket bekannt, weil Senator Hollings die Herausgabe von Informationen darüber verweigert und Anhörungen blockiert:
<http://www.newsforge.com/article.pl?sid=01/09/20/2047211>
Diese Typen müssen gestoppt werden, bevor sie die Computersicherheit für jeden zerstören.
Der SSSCA-Entwurf:
<http://cryptome.org/sssca.htm>

Es scheint als sei "Terrorist" die aktuelle Bezeichnung für jemanden, den man nicht mag. Michael Lane Thomas, Microsofts Senior-.NET-Entwickler-Evangelist, hat Virusautoren als "industrielle Terroristen" bezeichnet. Wie ich in der letzten Ausgabe schrieb, führt dies in die falsche Richtung und ist schädlich. Terroristen verursachen Terror und sollten nicht mit normalen Kriminellen verwechselt werden. Die Autoren von Schadsoftware sind unerfreulich -- sie verursachen Schaden, kosten Geld und zerstören Daten -- aber sie sind keine Terroristen.
<http://www.theregister.co.uk/content/56/22423.html>
<http://www.zdnet.co.uk/itweek/columns/2001/40/barrett.html>
Besonders störend ist die Art und Weise wie Thomas versucht, in dem Bemühen, die Leute zum Einsatz von Microsoft-Produkten zu bewegen, zu Patriotismus und Terrorismusbekämpfung aufzurufen. Er sagt, wenn die Leute aus Sicherheitsgründen aufhören, Microsofts IIS zu benutzen -- wie Gartner vor kurzem befürwortet hat -- dann "würde damit lediglich erreicht, was die industriellen Terroristen wollen."

Laut Voraussage von CERT wird die Menge von Computerangriffen dieses Jahr das Doppelte vom letzten Jahr betragen.
<http://www.securityfocus.com/news/266>
<http://www.zdnet.com/zdnn/stories/news/0,4586,5098301,00.html>

Es gibt eine Menge Neues bei NIST. Ein Report des Second Modes of Operation Workshops:
<http://csrc.nist.gov/encryption/modes/workshop2/index.html>
Änderungen im Standard zur Digitalen Signatur, FIPS 186-2. Neben anderem spezifiziert die Änderungsnotiz die empfohlenen Schlüsselgrößen und Modifikationen am RNG:
<http://csrc.nist.gov/encryption/tkdigsigs.html>
Das Key Management Schemes-Dokument für den Key Management Workshop, geplant für den 1.-2. November:
<http://csrc.nist.gov/encryption/kms/workshop2-page.html>

Ein neues Buch behauptet, dass eine Kryptanalystin die deutsche Chiffriermaschine Enigma vor dem zweiten Weltkrieg teilweise geknackt hatte, aber ihre Vorgesetzten ignorierten ihre Theorien.
<http://www.wired.com/news/women/0,1540,47560,00.html>

Eine neue Linux-Version wurde aus Furcht vor dem DMCA ohne Sicherheitsinformationen herausgebracht. Ehrlich gesagt sehe ich nicht, wie der DMCA hier anwendbar ist, aber dies ist ein guter Indikator für die herrschende Angst in der Community.
<http://www.securityfocus.com/news/274>
<http://www.securityfocus.com/columnists/35>

Sorgen über Angriffe von Insidern:
<http://www.computerworld.com/storyba/0,4125,NAV47_STO64774,00.html>

Guter Artikel über den Bedarf an Sicherheitsstandards für Software:
<http://www.computerworld.com/storyba/0,4125,NAV47_STO64757,00.html>

Funknetzwerke hacken:
<http://news.bbc.co.uk/hi/english/sci/tech/newsid_1596000/1596033.stm>

Microsofts DRM2, ihre neue Sicherheitssoftware zum Digital Rights Management, wurde geknackt. Ein Hackertool, das von jemandem mit dem Pseudonym Beale Screamer entwickelt wurde, kann den Kopierschutz von Audiodateien entfernen.
<http://www.theregister.co.uk/content/55/22354.html>
<http://news.cnet.com/news/0-1005-200-7590303.html>
<http://cgi.zdnet.com/slink?154661:8469234>
<http://cryptome.org/ms-drm.htm>
Einmal mehr lernen wir, das jeder digitale Kopierschutz geknackt werden kann. Dieser Crack ist nicht mal interessant.

Und Hacker aus Hong Kong machen aus dem Knacken von Microsofts Kopierschutz ein Geschäft:
<http://www.zdnet.com/zdnn/stories/news/0,4586,2821260,00.html>

Netter vierteiliger Artikel über Security Policies.
<http://www.securityfocus.com/cgi-bin/infocus.pl?id=1193>
<http://www.securityfocus.com/cgi-bin/infocus.pl?id=1473>
<http://www.securityfocus.com/cgi-bin/infocus.pl?id=1487>
<http://www.securityfocus.com/cgi-bin/infocus.pl?id=1497>

Identitäts-Diebstahl nimmt zu:
<http://cgi.zdnet.com/slink?154713:8469234>

Guter Artikel über Informationskriege:
<http://www.techreview.com/magazine/nov01/freedmanall.asp>

IDSs und ihre Komplexität:
<http://cgi.zdnet.com/slink?154665:8469234>

Weitere Neuigkeiten über die letztes Jahr aus Bletchley Park gestohlene Enigma-Maschine. Die Rotoren wurden wiedergefunden:
<http://news.bbc.co.uk/hi/english/uk/newsid_1609000/1609168.stm>

Zweiteiliger Artikel über Honeypots vom Honeynet-Projekt:
<http://www.securityfocus.com/cgi-bin/infocus.pl?id=1492>
<http://www.securityfocus.com/cgi-bin/infocus.pl?id=1498>

Essay von Whitfield Diffie und Susan Landau über die Implikationen von Microsofts .NET-Initiative für die Sicherheit und die Privatsphäre:
<http://www.kingpublishing.com/fc/new_technology/commentary.htm>

Sicherheitsleck in Software, die automatisch Antiviren-Software updated:
<http://www.zdnet.com/zdnn/stories/news/0,4586,2817368,00.html>

Vor einigen Monaten habe ich vor den Sicherheitsproblemen gewarnt, die Unicode mit sich bringen wird. Hier ist ein Beispiel:
<http://www.securityfocus.com/bid/3461>

Network Associates versucht PGP zu verkaufen:
<http://www.wired.com/news/privacy/0,1848,47551,00.html>
<http://www.securityfocus.com/news/264>

Gutes Beispiel der Realwelt-Risiken von vernetzten Systemen. Ein Australier wurde für schuldig befunden, sich in das computerisierte Abfallbeseitigungssystem von Queensland gehackt zu haben, wodurch mehrere Millionen Liter ungereinigter Abwässer in die regionalen Parks und Flüsse ausgelaufen sind.
<http://www.theregister.co.uk/content/4/22579.html>

Weitere Probleme mit Microsoft Passport:
<http://www.wired.com/news/technology/0,1282,48105,00.html>
<http://news.cnet.com/news/0-1003-200-7764433.html>
<http://www.washingtonpost.com/wp-dyn/articles/A33656-2001Nov3.html>
Es ist ein enormes Risiko, alle diese Informationen an einem einzigen Aufbewahrungsort unterzubringen. Und die Aussagen der Microsoft PR gehen völlig am Thema vorbei. Sie sagten: "Letztendlich ist der entscheidende Punkt, dass es keine Belege dafür gibt, dass dies irgendjemand jemals ausgenutzt hat." Erstens, würde es irgendwelche Belege geben? Zweitens, das wirkliche Problem sind die zukünftigen Risiken, nicht die derzeitigen Verletzungen. Und drittens, auf welcher Grundlage sollte ich weiterhin Microsofts nichtssagenden Sicherheitsversprechen trauen?

Website über die Sicherheitslücken in Passport:
<http://alive.znep.com/~marcs/passport/>

Nach einer Entscheidung eines kalifornischen Berufungsgerichts handelt es sich bei DeCSS um "Sprache". Gute Neuigkeiten!
<http://www.wired.com/news/print/0,1294,48075,00.html>
<http://www.courtinfo.ca.gov/courts/courtsofappeal/6thDistrict/>
<http://slashdot.org/yro/01/11/01/1953236.shtml>
<http://www.theregister.co.uk/content/55/22613.html>

Ein GSM-Telefon mit Ende-zu-Ende-Verschlüsselung:
<http://www.pcworld.com/news/article/0,aid,51368,00.asp>

Essay über die Probleme mit "Security by Obscurity." Führt an, dass Microsoft dieses Jahr sehr wahrscheinlich seinen Rekord an Sicherheitspatches brechen wird: über 100. (Also zwei pro Woche.)
<http://www.vnunet.com/Analysis/1126488>

Innerhalb von Stunden nach der Herausgabe von Windows XP brachen Piraten das Kopierschutzverfahren und begannen mit der Verteilung gestohlener Kopien.
<http://www.newsbytes.com/news/01/171651.html>
Microsofts Äußerungen hierzu sind korrekt. Es gibt zweifellos Sicherheitsrisiken bei der Benutzung von Raubkopien.

Mehr Sicherheitsdaten: Eine Untersuchung besagt, dass einer von neun IIS-Servern von Hackern übernommen werden kann. Ist es ein Wunder, dass Gartner zum Wechsel rät?
<http://www.infoworld.com/articles/hn/xml/01/11/02/011102hnsurvey.xml>

Eine andere Untersuchung besagt, dass zwei Drittel aller Funknetzwerke in London komplett offen sind:
<http://news.bbc.co.uk/hi/english/sci/tech/newsid_1639000/1639661.stm>

Hackingtools werden schlimmer:
<http://www.computing.vnunet.com/News/1126643>
<http://www.securityfocus.com/news/280>

Counterpane Internet Security News

Es sind einige bedeutsame Monate für Counterpane. Wir bekommen neue Monitoring-Kunden in bisher beispielloser Zahl. Wir haben die besten Sicherheits-VARs des Landes bekommen -- bedeutende nationale Reseller wie VeriSign und NEC, genauso wie exzellente lokale Reseller wie Accudata, FishNet, Espiria und Cadre Systems -- die Counterpane Monitoring verkaufen. Wir haben jetzt das "Counterpane Protected"-Programm gestartet. Industrie-Analysten empfehlen Counterpanes Fähigkeiten und Möglichkeiten.

Counterpane Protected:
<http://www.counterpane.com/protected.html>
<http://www.counterpane.com/pr-protected.html>

Analysten-Kommentare:
<http://www.counterpane.com/analyst.html>

Schneier spricht in Dallas (11/28), Baltimore (12/3), und New York (12/5):
<http://www.techmecca.net/>
<http://www.medrecinst.com/conferences/security/index.shtml>
<http://www.infosecurityevent.com/>

GOVNET

Die U.S.-Regierung möchte ihr eigenes privates Internet. Die Idee ist der Aufbau eines sicheren GOVNETs, das vom öffentlichen Internet physikalisch getrennt ist. Ich denke dies ist eine gute Idee, obwohl es sehr teuer und schwierig zu realisieren sein und mit ziemlicher Sicherheit Unsicherheiten aufweisen wird. Aber selbst eine mittelmäßige Implementierung würde sicherer sein als das was sie jetzt haben.

Die Beschränkung des Zugriffs auf ein Netzwerk hat weitreichende Auswirkungen bezüglich der Verbesserung der Sicherheit. Hacker können nicht von überall auf der Welt versuchen, in das Netz einzubrechen. Gutmeinende Freunde können keine Viren einschleppen. Trojaner können ihre Besitzer nicht über erfolgreiche Infektionen benachrichtigen. Benutzer können fragwürdige Websites nicht mehr besuchen und dabei ihre Passworte, die Konfigurationen und private Informationen rausgeben. Außenstehende können keine Passworte ausspähen. Die Software wäre genauso fehlerhaft -- Applikationen und Betriebssysteme würden dieselben Sicherheitslücken aufweisen -- aber der Zugriff auf die Sicherheitslücken wäre sehr viel schwieriger.

Die Effektivität dieser Maßnahmen ist direkt daran gebunden, wie stark die physikalische Trennung ist. Die Netzwerke müssen physikalisch unterschiedlich sein. GOVNET kann nicht über VPNs am Internet laufen. GOVNET kann keine mit Firewalls geschützten Gateways zum Internet haben. GOVNET kann nicht mit einem dieser albernen "Air-Gap"-Produkte vom Internet getrennt werden. GOVNET muß seine eigenen Router, seine eigenen Server und seine eigenen Clients benutzen. Wenn ein GOVNET-Benutzer das Internet benutzen möchte, benötigt er zwei Computer auf seinem Schreibtisch. Er kann auf beiden dieselben Programme benutzen, aber es müssen unterschiedliche Kopien sein. Und er kann keine Dateien zwischen beiden austauschen, nicht einmal per Diskette.

Der Bruch jeder dieser Regeln verletzt die Sicherheit. Der Austausch einer Diskette mit einer MS Word-Datei zwischen den beiden Netzwerken beinhaltet das Risiko der Infektion mit einem Makrovirus. Die Anbindung eines Computers an beide Netzwerke beinhaltet das Risiko, dass Schadsoftware überspringt. Die Erweiterung durch öffentliche Dial-Up-Zugangspunkte ermöglicht der Öffentlichkeit Einbruchsversuche.

GOVNET ist keine neue Idee. Es gibt bereits verschiedene getrennte Netzwerke der U.S.-Regierung -- INTELINK, SIPRNET, NIPRNET, usw. -- einige von diesen sind als Classified eingestuft. Die Classified-Netzwerke sind vollständig verschlüsselt, und alle Zugangspunkte befinden sich in abgesicherten Räumen und Gebäuden. Sie sind erheblich sicherer als das Internet, aber der Melissa-Virus benötigte 24 Stunden, um vom Internet auf eines dieser Netzwerke überzugreifen. Und der LoveLetter-Virus infizierte einige dieser Computer.

Ich kann mir vorstellen was passierte. Ein rangälterer Geschäftsführer prüfte seine E-Mail im Internet. Dann schloss er denselben Laptop an eines der privaten, sicheren, als Classified eingestuften und getrennten Netzwerke an. Und der Virus kam rüber.

Aber selbst das ist um Welten besser als das, was wir heute haben. Und ein von Null an neu designtes GOVNET kann andere Sicherheitsmaßnahmen beinhalten. Dort kann es vorgeschriebene starke Authentisierung geben (insofern wie kommerzielle Produkte dies erlauben). Alle Verbindungen können verschlüsselt werden. Anonymität kann verboten werden. Es kann besser geregelte Verantwortlichkeiten geben. Es kann eine geprüfte Liste der erlaubten Software geben. GOVNET kann Angriffe von Innen nicht verhindern, aber es könnte ihre unerkannte Durchführung wesentlich schwieriger machen.

Auf der anderen Seite macht die physikalische Trennung vom Internet ein Netzwerk sehr viel nutzloser. Und Nützlichkeit ist der Hauptgrund, warum Firmen ihre Firmennetzwerke an das Internet anschließen. In vielen Belangen ist dies ein großer Schritt rückwärts. Das Internet bekam seinen Namen, weil es ein Netzwerk der Netzwerke war. In den frühen Zeiten gab es das Arpanet, Milnet, BITnet, Usenet, JANET, und eine Masse an weiteren unzusammenhängenden Netzwerken. Ihr Anschluss an das Internet machte sie alle nützlicher.

Soweit wie GOVNET (und die anderen) sich selbst vom Internet abtrennen, werden sie weniger nützlich. Netzwerke wie INTELINK haben wohldefinierte Einsatzzwecke; deshalb funktionieren sie. GOVNET hat dies nicht, und das ist seine größte Schwäche. Die Benutzer werden den Zugang zu Teilen des Internets benötigen, und die Versuchung wird immer vorhanden sein, die Anbindung an das Internet über eine Art von Firewall durchzuführen. Und dann ist die Trennung nicht mehr vorhanden. Unglücklicherweise ist die Sicherheit von etwas wie GOVNET umgekehrt proportional zu seinem Nutzen.

Pressemitteilung:
<http://w3.gsa.gov/web/x/publicaffairs.nsf/dea168abbe828fe9852565c600519794/
1c10e9ac670553b885256ae100668beb?OpenDocument>

News und Kommentare:
<http://news.bbc.co.uk/low/english/sci/tech/newsid_1601000/1601823.stm>
<http://www.theregister.co.uk/content/archive/22156.html>
<http://www.zdnet.com/zdnn/stories/news/0,4586,5098134,00.html>
<http://www.zdnet.com/zdnn/stories/news/0,4586,5098169,00.html>
<http://www.zdnet.com/sp/stories/news/0,4538,2818268,00.html>
<http://www.zdnet.com/zdnn/stories/news/0,4586,2818103,00.html>
<http://www3.gartner.com/DisplayDocument?doc_cd=101741>

Sicherheitslücke in Password Safe

Password Safe ist ein kostenloses Windows-Utility zum sicheren Aufbewahren von Passworten. Ich entwickelte es, als mir zum ersten mal bewußt wurde, dass ich mir zu viele Passworte merken musste. Ich hätte entweder schwache Passworte wählen können -- oder Passworte für unterschiedliche Zwecke wiederverwenden -- oder ein Programm schreiben, dass Passworte auf der Festplatte verschlüsselt. Dies ist die Grundidee: Wähle ein starkes Passwort (oder eine Passphrase) und verschlüssele alle anderen Passworte mit diesem Passwort und Password Safe. Password Safe ist klein und einfach; es wurde dazu designed, eine Sache gut durchzuführen, und ist nicht mit Features und Optionen überladen.

Vor kurzem wurde eine kleine Sicherheitslücke in Password Safe entdeckt. In einigen Fällen, wenn man Password Safe mit den aktivierten Optionen "clear clipboard when minimized" und "lock password database on minimize" minimiert, hinterläßt die Windows-Speicherverwaltung einen Benutzernamen oder ein Passwort im Speicher. Die Kombination des Master-Safes kann nicht im Speicher zurückbleiben, aber das zuletzt benutzte gespeicherte Passwort. Diese Lücke wurde unter Windows 95 gefunden, und wir wissen noch nicht, ob dies auch unter anderen Windows-Versionen passiert. (Ich würde annehmen, dass es der Fall ist, bis das Gegenteil bewiesen wird.)

Es ist leicht, mit der Sicherheitslücke zu leben. Das Programm muss zwischen den einzelnen Benutzungen komplett geschlossen werden. Man sollte sich nicht auf das password-on-restore-Feature der PS 1.7.x gegen einen Angreifer verlassen, der z.B. das Laptop stiehlt. Und wenn password-on-restore sowieso nicht benutzt wird, stellt dies ohnehin kein Problem dar.

Ist dies wirklich eine Sicherheitslücke? Ja. Ist Password Safe weiterhin sicher? Ja, und ich habe deswegen nicht aufgehört, es zu benutzen. Ist dies etwas, das beseitigt werden sollte? Ja.

Password Safe sollte auf jeden Fall ein Update bekommen. Ich habe eine Liste von etwa einem Dutzend kleinerer Optimierungen und Verbesserungen, und das Programm muss unter Windows XP geprüft werden. Und es ist erforderlich, dass Password Safe Open Source wird. Aber ich habe nicht die Zeit dazu.

Wenn irgendjemand die Verantwortung für die Programmierung von Password Safe übernehmen möchte, würde ich gerne davon erfahren. Ich suche jemanden, der in der Windows-Programmierung erfahren ist, speziell in Bezug auf die Lücke in der Speicherverwaltung, die diese Sicherheitslücke aufzeigt, und jemanden der bereit ist, diese Arbeit gratis (für Ruhm und Glorie) an einem freien Stück Software durchzuführen. Ich möchte die Kontrolle über das Projektdesign behalten, würde mich aber freuen, den Sourcecode frei verfügbar zu machen. Ich würde ebenfalls gerne Password Safe auf den Macintosh und das Palm OS portieren.

Interessierte sollten mir eine E-Mail senden.

Password Safe:
<http://www.schneier.com/passsafe.html>

Beschreibung der Sicherheitslücke:
<http://cert.uni-stuttgart.de/archive/bugtraq/2001/09/msg00158.html>

Microsoft über Windows XP

eWeek übertrug ein Interview mit Jim Allchin, VP der Microsoft Platform Group. Ich möchte zwei Aussagen daraus zitieren und kommentieren.

"Windows XP ist dramatisch Sicherer als Windows 2000 oder jedes der Vorgänger-Systeme. Buffer Overflows sind eine der Angriffsformen, die immer wieder über das Internet ausgeführt werden. Wir sind den gesamten Code durchgegangen und haben, auf eine automatisierte Weise, Stellen gefunden an denen Buffer Overflows auftreten könnten, und diese wurden in Windows XP beseitigt.

Wir haben außerdem eine ganze Menge Sachen als Defaulteinstellung abgeschaltet, so dass die Benutzer eine minimalistische Art der Konfiguration vorfinden, die sie weniger angreifbar macht. Wir haben außerdem eine ungesicherte Win XP-Maschine ins Internet gestellt und lassen die Leute versuchen, sie zu knacken. Bisher gab es so weit keine Einfallstore und keine Vorfälle."

Ich werde dieses Zitat gerne aufbewahren. Jedes mal, wenn Microsoft ein neues Betriebssystem herausbringt, behaupten sie, dass es dramatisch sicherer ist als das vorhergehende Betriebssystem. Sie sagten das von Windows NT. Sie sagten das von Windows 2000. Jedes mal lagen sie falsch. Wir werden in einem Jahr oder so auf das obige Zitat zurückkommen.

"Wir testen alle Sicherheitskorrekturen. Mit all den Sicherheitskorrekturen, die wir in den letzten 10 Jahren veröffentlicht haben, gehen wir für jeden einzelnen durch eine Regression, wir stellen ihn auf die Microsoft Website, bevor wir ihn weiter veröffentlichen, wir lassen ihn hier in der Produktion laufen, und wir fühlen uns über die Qualität des ganzen sehr zuversichtlich.... Die Sicherheitskorrekturen, die wir produzieren, enthalten keine andere Funktionalität; sie wurden speziell zum Entfernen einer potenziellen Einbruchstelle designed."

Dafür mussten wir nicht mal ein Jahr warten. Am selben Tag, an dem dieses Interview gelaufen ist, musste Microsoft einen Sicherheitspatch zurückziehen, weil er in den Netzwerken der Benutzer Fehlfunktionen auslöste. Oops. So viel zum regressiven Testen, so viel zum Testen von Patches in Microsofts eigenem Netzwerk.

Und ein anderer Microsoft-Patch, derjenige der die unangenehme Sicherheitslücke beseitigen sollte, die in MS01-50 beschrieben wurde, war schwer zu installieren, teilweise wegen "Microsofts Entscheidung, eine Anzahl an Berichtigungen einzubringen, die nichts mit Sicherheit zu tun haben, wie z.B. die Korrektur eines Excel-Fehlers beim Sortieren von Tschechisch-sprachigen Listen" (laut Business Week).

Ich habe lange bemängelt, dass Microsoft Sicherheitsheitsprobleme als PR-Probleme behandelt, und dies ist nur ein weiterer Beleg dafür. Sie sagen der Presse gegenüber immer wieder die Unwahrheit, wenn sie über Sicherheit sprechen, wie sich wieder und wieder an ihren Handlungen zeigt.

Das Allchin-Interview in eWeek:
<http://www.eweek.com/article/0,3658,s%3D701%26a%3D16895,00.asp>

Microsofts fehlerhafter Patch:
<http://www.computerworld.com/storyba/0,4125,NAV47_STO64947,00.html>
<http://www.pcmag.com/article/0,2997,s=1490&a=16909,00.asp>
<http://www.internetnews.com/dev-news/article/0,,10_908671,00.html>
<http://www.theregister.co.uk/content/4/22382.html>

Microsoft steckt andere Updates in einen Sicherheitspatch:
<http://www.businessweek.com/magazine/content/01_46/b3757023.htm>

Leserkommentare

<http://www.schneier.com/crypto-gram-0111.html#8>

Crypto-Gram ist ein kostenloser monatlicher Newsletter mit Zusammenfassungen, Analysen, Einsichten und Kommentaren über Computersicherheit und Kryptographie. Ältere Ausgaben und die Möglichkeit des Abonnements stehen hier zur Verfügung:
<http://www.schneier.com/crypto-gram.html>

Die deutschen Übersetzungen stehen hier zur Verfügung:
<http://archiv.galad.com/cg/cg.htm>

Die deutsche Übersetzung von Crypto-Gram darf an interessierte Kollegen und Freunde weiterverteilt werden. Die Erlaubnis zum Nachdruck der deutschen Übersetzung von Crypto-Gram ist gewährt, solange die Wiedergabe als Gesamtheit erfolgt. Die LinkMap kann selbstverständlich entfernt werden.

Bruce Schneier ist der Verfasser von Crypto-Gram. Schneier ist der Gründer und CTO der Counterpane Internet Security Inc., der Autor von "Secrets and Lies" und "Applied Cryptography", und ein Erfinder der Blowfish-, Twofish- und Yarrow-Algorithmen. Er ist ein Mitglied des Beraterboards des Electronic Privacy Information Centers (EPIC). Er ist ein regelmäßiger Autor und Dozent über Computersicherheit und Kryptographie.

Deutsche Übersetzung von Holger Hasselbach, galad.com, mit freundlicher Erlaubnis der Counterpane Internet Security, Inc.