Skip to content

Adobe: Lieber Exploits verteuern statt Schwachstellen beheben

Software wird nie völlig fehlerfrei sein. Um so wichtiger ist es, sie so fehlerfrei wie möglich zu machen. Und das bedeutet insbesondere, erkannte Schwachstellen zu beheben und das Entstehen von Schwachstellen möglichst zu verhindern. Dass das möglich ist, hat Microsoft bewiesen. Adobe setzt dagegen auf Mitigations, um Angriffe zu verteuern.

Löcher im Dach

Betrachten wir vorab mal ein "Real-World"-Beispiel, und zwar einen Hausbesitzer. Wenn dessen Hausdach ein Loch hat und es durch regnet, stellt er erst mal einen Eimer drunter, um das Loch dann so schnell wie möglich zu schließen (oder von einem Dachdecker schließen zu lassen). Bei der Gelegenheit wird er dann auch gleich nach weiteren Löchern suchen, man hat ja i.A. Besseres zu tun, als ständig auf dem Dachboden Eimer aufzustellen. Hat das Dach gleich mehrere Löcher, ist die Reparatur um so dringender, denn sonst hat er nach dem nächsten Sturm zwar vielleicht noch ein Dach, aber das liegt dann unten auf der Straße statt oben auf dem Haus.

Mitunter ist es auch ratsam, Löcher im Dach z.B. mit einer Plastikplane abzudecken, um Folgeschäden zu verhindern. Geflickt werden müssen die Löcher natürlich trotzdem. Das gleich gilt natürlich, wenn unter den Dachziegeln bereits vorsichtshalber eine Plane angebracht ist. Die verhindert zwar, dass es rein regnet, wenn ein Dachziegel fehlt, aber nicht, dass ein Sturm nach und nach das ganze Dach abdeckt. Was dem um so leichter fällt, je mehr Löcher das Dach bereits hat.

Irgendwann besteht das Dach aus so vielen Flickstellen oder demnächst kaputt gehenden Stellen, dass statt einer Reparatur eine neue Dacheindeckung fällig wird.

Jetzt übertragen wir das mal auf Software: Die Löcher im Dach sind dann Schwachstellen im Programm.

Microsoft flickt

Genau das gleiche Problem wie der oben angenommene Hausbesitzer hatte Microsoft vor 10 Jahren: Etliche Würmer nutzten Schwachstellen in Windows zur Verbreitung, und generell gab es in den Microsoft-Programmen viel zu viele Schwachstellen. Mitigations wie DEP und ASLR gab es damals noch nicht, im obigen Beispiel würden also die Eimer fehlen und das Wasser munter ins Haus laufen, bis es zu regnen aufhört oder die Löcher geflickt sind.

Bill Gates schickte damals eine inzwischen berühmte E-Mail an alle Mitarbeiter und führte damit bei Microsoft das "Trustworthy computing" ein (genau das war auch das Subject der Mail). In einem ersten Schritt wurden mehrere laufende Entwicklungsprojekte gestoppt und die Entwickler zu IT-Sicherheits-Schulungen geschickt, bevor sie ihre Arbeit fortsetzen durften.

2004 wurde dann der "Security Development Lifecycle" (SDL) entwickelt, der seitdem Grundlage jeder bei Microsoft entwickelten Software ist. Und der SDL hat sich ausgezeichnet bewährt: Das erste vollständig nach dem SDL entwickelte System war Windows Vista, in dem im ersten Jahr nach seiner Veröffentlichung 45% weniger Schwachstellen gefunden wurden als im ersten "Lebensjahr" von Windows XP.

Microsoft hat also genau das gemacht, was auch jeder vernünftige Hausbesitzer machen würde: Die Schwachstellen behoben und dafür gesorgt, das möglichst keine neuen dazu kommen. Und als sich die Reparatur nicht mehr lohnte, gab es ein neues Dach, Pardon, Programm. Außerdem gibt es inzwischen die Mitigations, die eine Ausnutzung von Schwachstellen erschweren sollen und die quasi die Eimer im obigen Beispiel darstellen.

Das kann man so machen. Man kann es aber auch bleiben lassen. Aber was würden Sie von einem Hausbesitzer halten, der statt die Problemstellen zu reparieren lieber eine Maschine erfindet, die automatisch Eimer unter die neuen undichten Stellen stellt? Dass die Eimer auch mal überfließen oder selbst ein Loch haben, ist ihm egal - unter den meisten Löchern stehen heile Eimer, das reicht ihm.

Und was würden Sie sagen, wenn dieser Hausbesitzer nun auch noch ein Haus aus luftgetrockneten Lehmziegeln bewohnt? Sollte er dann nicht erst recht auf ein dichtes Dach achten? Dass ihm irgendwann das Dach weg fliegt und das dann vielleicht einem unbeteiligten Dritten auf den Kopf fällt, ist dann noch ein weiteres Problem.

Sie denken, so etwas gibt es nicht? Nun ja, im Fall von Hausdächern haben Sie hoffentlich recht, bei der Software aber leider nicht. Da gibt es nämlich Adobe, und Adobe hält nichts von sicherer Software, da erfindet man lieber neue Eimer-Aufstell-Maschinen:

Adobe steckt den Kopf in die Sandbox

Brad Arkin, Adobes "Security Chief", hat auf dem "Kaspersky Security Analyst Summit" eine Keynote gehalten und sich über Forscher aufgeregt, die Mitigation-Technologien analysieren und Schwachstellen darin bzw. Anleitungen zum Umgehen der Mitigations veröffentlichen. Denn diese Ergebnisse werden von den Cyberkriminellen genutzt, um ihre Exploits zu verbessern.

Erst mal gilt hier das gleiche Argument wie bei Schwachstellen allgemein: Die Schwachstellen entstehen nicht, wenn sie entdeckt werden, sondern schon, wenn der entsprechende Code geschrieben wird. Wenn die Mitigations nicht so funktionieren, wie man sich das bei Adobe vorstellt, dann deshalb, weil man sie nicht anständig implementiert oder konzipiert hat. Und das kommt nun mal früher oder später raus. Zwischen 0-Day-Schwachstellen in Adobe Reader oder Flash Player und 0-Day-Schwachstellen in Mitigations besteht erst kein Unterschied.

Aber warum ist man bei Adobe so sauer auf die veröffentlichten Angriffe auf die Mitigations? Die sollen ja Angriffe nur erschweren und nicht verhindern. Genau darauf setzt man aber bei Adobe: Statt die Schwachstellen zu beheben, möchte man lieber deren Ausnutzung verteuern. Das diese Taktik nicht aufgeht, liegt natürlich nur an den Forschern, die Schwachstellen in den Mitigations kostenlos an die Cyberkriminellen liefern. Meint Brad Arkin.

Aber noch mal von vorn. Dazu zwei Zitate aus dem Bericht über die Keynote:

"My goal isn’t to find and fix every security bug," Arkin argued. "I'd like to drive up the cost of writing exploits. But when researchers go public with techniques and tools to defeat mitigations, they lower that cost."
(Hervorhebung von mir)

und

"We may fix one vulnerability that has a security characteristic but when we change that code, we are creating a path to other vulnerabilities that may cause bigger problems in the future."

Und so geht es weiter. Adobe hat in den vergangenen Jahren Hunderte von Schwachstellen gepatcht, aber nur für wenige davon gab es Exploits. Dass diese wenigen Exploits Tausenden oder Millionen von Benutzern Schadsoftware eingebracht haben, wird dabei mal eben übersehen. Da es sowieso keine vollständig sichere Software gibt, möchte Adobe lieber die Exploitentwicklung verteuern. In der Hoffnung, dass die Cyberkriminellen dann irgendwann aufgeben. Fragt sich nur, warum sie das sollten. Denn Brad Arkins Ausgangshypothese ist zumindest zum Teil falsch:

"Financially motivated attackers don't invest in original research. It's too expensive these days," Arkin said. "It's pen testers or it's nation states or the people funded by them. That research is done by profession bad guys who have financial horizons that far exceed those of financially motivated bad guys."

Auch viele unabhängige Forscher untersuchen die Mitigations - zum Teil kostenlos in ihrer Freizeit. So "expensive" ist das also gar nicht. Und warum sollten die Cyberkriminellen nicht in entsprechende Forschung investieren, wenn es nötig ist? Das sie es bisher nicht getan haben, hat den einfachen Grund, dass es nicht nötig war. Daraus zu schließen, dass sie es auch nicht tun werden, wenn es mangels kostenloser Informationen Dritter nötig wird, ist doch ziemlich naiv. Das ist ein Milliarden-Euro-Markt, warum sollten die Cyberkriminellen nicht einen Teil ihrer Gewinne für zukünftige Angriffe einsetzen, wenn sie sich damit ihr Geschäft sichern?

Statt also sichere Software zu entwickeln und alle bekannten Schwachstellen zu beheben, möchte man lieber den Kopf in den Sand und die Programm in eine Sandbox stecken und hoffen, dass dann nichts passiert.

Ich stelle daher fest: Adobe hat kein Interesse an der Entwicklung sicherer Software (siehe hervorgehobenen Text im ersten Zitat). Da ich kein Interesse an unsicherer Software habe, ist die Schlussfolgerung wohl klar: "Adobe - Nein Danke"!.

Das ist auch weiter kein Problem, da Flash in Zeiten von HTML5 sowieso überflüssig ist (was sich nur leider nicht zu einigen Onlinebanking-Entwicklern rumgesprochen hat) und es für den Adobe Reader deutlich schlankere und sichere Alternativen gibt (was beides keine große Kunst ist).

Bedenklich ist nur, das Adobe versucht, andere Softwarehersteller ebenfalls auf diese Irrweg zu führen Hoffen wir mal, dass die schlau genug sind, lieber Microsofts Weg zu sicherer Software zu folgen statt Adobes Weg in die Unsicherheit.

Carsten Eilers

Trackbacks

Dipl.-Inform. Carsten Eilers am : 2013 - Die Zukunft hat schon begonnen!

Vorschau anzeigen
Traditionell werden zum Jahresende Prognosen für das Folgejahr veröffentlicht. Das ist im Bereich der IT-Sicherheit eigentlich ganz einfach, man muss nur den Grundsatz von Bernd dem Brot abwandeln: "Alles wird wie immer, nur schlimmer"

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

Noch keine Kommentare

Kommentar schreiben

Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
BBCode-Formatierung erlaubt
Formular-Optionen

Kommentare werden erst nach redaktioneller Prüfung freigeschaltet!