Microsoft und die Vertrauensfrage
Microsoft schien in Bezug auf Sicherheit in den letzten Monaten auf dem richtigen Weg zu sein. Bei Fehlern in Service Pack 2 scheint jetzt aber wieder das alte "Das ist kein Bug, das ist ein Feature" durch.
Microsoft schien in den letzten Monaten auf dem richtigen Weg zu sein. Sie haben lange bekannte Bugs endlich als solche anerkannt und das vorher als notwendiges Design-Feature deklarierte Verhalten von Funktionen geändert. Mit ADODB.stream konnten viele Internet-Explorer-Exploits ihren Unrat direkt auf die Festplatte schreiben -- nur weil ein Anwender leichtsinnigerweise die falsche Web-Seite geöffnet hatte. Microsoft zog sich etwa ein Jahr lang auf die altbekannte Argumentationsschiene "Das ist kein Bug, das ist ein Feature" zurück. Dann kam Download.JECT und letzten Monat haben die Redmonder ADODB.stream mit einem eiligen Sicherheits-Update im Internet Explorer deaktiviert. Es keimte die Hoffnung, da hätte sich doch noch ein grundsätzlicher Wandel vollzogen und der Softwareriese meine es mit der Sicherheit seiner Kunden endlich ernst.
Jetzt finde ich bereits nach wenigen Tagen Herumspielen mit den neuen Sicherheitsfunktionen von Service Pack 2 den ersten Fehler: Der Windows Explorer startet eine Datei, die als unsicher markiert ist, ohne die fällige Warnung, weil sein Cache noch eine veraltete Sicherheitsinformation enthält, die von einer überschriebenen Datei gleichen Namens stammt. Ein klarer Programmierfehler. Nichts vom Kaliber ADODB, aber ein Bug der so schnell wie möglich beseitigt werden sollte. Also fülle ich einen Report auf Microsofts Feedback-Seite aus. Das Microsoft Security Response Center antwortet: "Das von Ihnen beobachtete Verhalten widerspricht nicht den Design-Zielen dieses Features" und "derzeit betrachten wir dies nicht als Angelegenheit, für die wir einen Patch oder Workaround entwickeln würden."
Da ist es wieder: das alte Microsoft, das sich auf Formulierungen wie "Das ist kein Bug, das ist ein Feature" zurückzieht. Das Kalkül ist klar: Wenn Microsoft schon wenige Tage nach der Veröffentlichung von Service Pack 2 zugäbe, dass eine der neuen Sicherheitsfunktionen einen Fehler enthält, gäbe das ein großes Medienecho. Da nimmt man lieber in Kauf, dass sich ein paar Sicherheitsexperten verwundert die Augen reiben, hofft, dass schon nichts Ernstes passiert und die Diskussion darüber auf Insider-Kreise beschränkt bleibt.
Vielleicht klappt das in diesem Fall sogar. Doch die langsam aufkeimende Zuversicht, da könnte sich was Grundsätzliches bei Microsoft geändert haben, bleibt auf der Strecke. Auf lange Sicht wird sich dieses Verhalten rächen. Denn das Vertrauen, das "Trustworthy Computing" proklamiert, muss man langsam und kontinuierlich aufbauen - verspielt ist es jedoch schnell.
Ein Bug ist ein Bug -- und er verschwindet nicht, indem man passende Design-Ziele definiert. Gerade bei Sicherheitsfunktionen sollten Fehler möglichst schnell beseitigt werden, auch wenn noch keine Möglichkeit bekannt ist, wie Angreifer sie direkt ausnutzen können. Zu oft haben wir in letzter Zeit gesehen, wie erst das Zusammenspiel von mehreren kleineren Problemen, die sich einzeln nicht ausnutzen ließen, zum GAU führte. Download.JECT war dafür ein klassisches Beispiel. Wir können nur hoffen, dass Microsoft das Cache-Problem des Explorers doch noch fixt, bevor es wieder knallt.
