Skip to content

Pwn2Own 2011 - Schlechtere Regeln, Googles Chrome erneut ungetestet

Der Pwn2Own-Wettbewerb auf der Sicherheitskonferenz CanSecWest verlief eigentlich fast so wie in den Vorjahren, zumindest soweit es die Webbrowser betrifft. Trotzdem gab es zwei (oder eigentlich drei) Auffälligkeiten. Zum einen wurde Chrome zum dritten Mal in Folge nicht getestet, zum anderen wurden die Regeln für den Wettbewerb geändert - und das eindeutig zum Nachteil. Und Charlie Miller konnte seine Erfolgsserie im Knacken von Safari unter Mac OS X nicht fortsetzen. Aber fangen wir mit den Regeln an:

Viel Aufwand für wenige Gewinne

Die Zero Day Initiative (ZDI) als Veranstalter des Wettbewerbs hat die Regeln im Vergleich zu den Vorjahren verschlechtert: Der erste, der einen Browser erfolgreich angreift, bekommt sowohl ein Preisgeld als auch das Gerät, auf dem der angegriffene Webbrowser läuft. Außerdem gibt es "ZDI reward points". Danach ist der Browser aus dem Rennen. Und das ist die Verschlechterung im Vergleich zu den Vorjahren, in denen der Browser danach weiterhin angegriffen werden konnte. Für die weiteren erfolgreichen Angreifer gab es dann "nur" einen Geldpreis und die Gummipunkte, aber das ist immer noch deutlich mehr als in diesem Jahr. Im Gegenzug treten die Gewinner ihre Exploits und die gefundenen Schwachstellen an die Zero Day Initiative ab, die sie dann an die jeweiligen Hersteller meldet.

Während in den Vorjahren alle entwickelten Exploits ausprobiert und die verwendeten Schwachstellen im Erfolgsfall an die Hersteller gemeldet wurden, blieben dieses Jahr alle außer dem jeweils ersten erfolgreichen Exploit quasi "auf dem Mark". Und das beim bisher größten Teilnehmerfeld aller Wettbewerbe: Für Safari interessierten sich 4 Personen oder Teams, für den Internet Explorer drei und für Firefox und Chrome je zwei. Gewinnen konnte bei jedem Browser nur eine Person oder ein Team, alle anderen gingen leer aus. Egal wie ausgefeilt der Exploit oder wie schwer zu finden die ausgenutzte Schwachstelle war, wer beim Auslosen Pech hatte und nach einem erfolgreichen Angreifer an der Reihe war, kam gar nicht mehr zum Zuge.

Was macht man denn in so einem Fall mit der gefundenen Schwachstelle und dem mühsam entwickelten Exploit? Aufheben fürs nächste Jahr, vielleicht bleibt die Schwachstelle dem Hersteller bis dahin ja unbekannt und mit etwas mehr Losglück gibt es dann einen Gewinn? Oder irgend wo anders (oder auch an die Zero Day Initiative) verkaufen? Immerhin geht es hier nicht um reine Proof of Concepts, sondern um voll funktionsfähige Angriffe, und die dürften auf dem Schwarzmarkt deutlich mehr einbringen als die normalen Ankaufpreise z.B. der Zero Day Initiative. Und schließlich haben die Entwickler daran ja ziemlich lange gearbeitet, dann sollte sich der Aufwand doch auch lohnen.

Die neuen Regeln hat auch Charlie Miller kritisiert, und das m.E. völlig zu Recht. Erst die Forscher zum Entwickeln von Exploits auffordern und diese dann nicht belohnen, ist keine gute Idee. Einer der Veranstalter sieht das anders und kommentiert es mit

"The researchers who compete in Pwn2Own are doing so not merely for the money, but for the fame associated with the skills they demonstrate,"

Und warum haben sie sich dann zum Teil anonym angemeldet? Anonym erworbener Ruhm ist doch ziemlich unpraktisch, oder?

Ohne irgend jemanden etwas unterstellen zu wollen: Wer wollte wem einen Vorwurf machen, wenn demnächst eine neue 0-Day-Schwachstelle in einem der Browser auftaucht? Da niemand weiß, welche Schwachstellen die nicht zum Zuge gekommenen Teilnehmer gefunden haben, kann auch niemand feststellen, ob diese Schwachstellen später auf dem Schwarzmarkt landen, den Herstellern gemeldet oder einfach fürs nächste Jahr auf Halde gelegt werden. Aber das ist halt auch der Vorteil für die Zero Day Initiative, denn auch der kann man dann keinen Vorwurf machen. Was für ein glücklicher Zufall.

Aber kommen wir zu den Ergebnisse:

Charlie Miller ohne Losglück, Safari trotzdem geknackt

Die Startreihenfolge wurde ausgelost, und Charlie Miller, der bereits 2008 (in einem Team), 2009 und 2010 erfolgreich Safari unter Mac OS X angreifen und damit das jeweilige MacBook gewinnen konnte, hatte dabei Pech: Der Wettbewerb fing zwar mit Mac OS X und Safari an, der erste Versuch ging aber an Chaouki Bekrar und ein Team vom französischen Sicherheitsunternehmen VUPEN, dessen Angriff erfolgreich war. Damit war das MacBook vergeben und Charlie Miller konnte seine Siegesserie nicht fortsetzen. Vielleicht veröffentlicht er die Schwachstelle und den Exploit also demnächst.

Ausgenutzt wurde übrigens eine Schwachstelle im Webkit, aber das ist ja beim Pwn2Own-Wettbewerb eigentlich schon fast normal, lediglich beim ersten Wettbewerb 2007 wurde eine Schwachstelle in QuickTime ausgenutzt, um das MacBook zu übernehmen.

Internet Explorer 8 unter Windows 7 ebenfalls geknackt

Auch der Internet Explorer 8 unter Windows 7, der als nächstes an die Reihe kam, hielt den Angriff durch den ersten Teilnehmer, Stephen Fewer, nicht lange stand - trotz der aktivierten Schutzmaßnahmen DEP und ASLR, die einen Angriff bekanntlich erschweren. Auf threatpost gibt es ein Interview mit Stephen Fewer, der drei Schwachstellen ausnutzte, um DEP und ASLR sowie den Protected Mode zu umgehen.

Chrome und Mozilla Firefox ungetestet

Wie schon 2009 und 2010 blieb Chrome ungetestet. Und das, obwohl der mit Webkit die gleiche Rendering-Engine wie Dauerverlierer Safari verwendet. Ein Teilnehmer trat gar nicht erst an, ein Team gab an, keinen funktionsfähigen Exploit zu haben. Auch ein Team, das sich an Mozillas Firefox versuchen wollte, zog seine Anmeldung zurück.

Charlie Miller gewinnt iPhone

Bei dem Smartphones hatte Charlie Miller mehr Losglück und durfte als erster das iPhone 4 angreifen, und wie zu erwarten war: Er kam, griff (mit einer Drive-by-Infektion die mobile Version von Safari) an und siegte. Auch der BlackBerry Torch 9800 wurde erfolgreich angegriffen: Vincenzo Iozzo, Willem Pinckaers und Ralf Philipp Weinmann verbanden 3 Exploits, um erfolgreich Code auszuführen. Übrigens wurde auch dabei ein auf Webkit basierender Browser angegriffen. Ein angekündigter Angriff auf Windows 7 Mobile wurde zurückgezogen und auch an Android versuchte sich erst gar niemand.

Was ist an Chrome so besonders?

Wieso ist dies das dritte Jahr in Folge, in dem es keinen erfolgreichen Angriff auf Chrome gab? Chrome ist ein Webbrowser wie alle anderen auch, und er basiert noch dazu auf Webkit. Und Schwachstellen in Webkit haben sich bereits mehrmals als Garant für einen Pwn2Own-Gewinn erwiesen. Alle Angriffe auf Safari erfolgten über WebKit-Schwachstellen, und diesmal wurden WebKit-Schwachstellen auch für die Angriffe auf iPhone und BlackBerry verwendet. Wieso also gab es keine Angriffe auf Chrome?

Sandkastenspiele

Der einzige Unterschied zwischen Chrome und z.B. Safari ist die Sandbox, in die die einzelnen Renderer-Prozesse eingesperrt werden (die unterschiedliche JavaScript-Implementierung mal außen vor gelassen). Und die ist anscheinend so gut implementiert, dass niemand ein Interesse daran hat, einen WebKit-Exploit auf Chrome zu portieren. Und das, obwohl Google dieses Jahr 20.000 US-Dollar Preisgeld für einen erfolgreichen Ausbruch aus der Sandbox ausgelobt hat, wenn die Schwachstelle sich ausschließlich in Google-Code befindet.

Nun ist es unmöglich, eine Nichtexistenz zu beweisen. Nur, weil niemand einen funktionsfähigen Exploit für Chrome veröffentlicht hat, bedeutet das nicht, dass es nicht vielleicht doch einen gibt. Aber es ist doch ein starkes Indiz dafür, dass es zumindest zur Zeit keinen entsprechenden Exploit gibt. Oder dass der dem Entwickler mehr wert ist als die gebotenen 20.000 US-Dollar. Auf jedem Fall sollten sich andere Hersteller aber vielleicht mal überlegen, ob sie nicht auch eine Sandbox verwenden sollten.

Carsten Eilers

Trackbacks

Dipl.-Inform. Carsten Eilers am : Apples Umgang mit Schwachstellen und deren Entdeckern

Vorschau anzeigen
Charlie Miller, der bereits etliche Schwachstellen in Mac OS X, Safari und iOS gefunden und seit 2008 alle Pwn2Own-Wettbewerbe gewonnen hat, hat wieder zugeschlagen: Eine von ihm entdeckte Schwachstelle in iOS erlaubt das Einschleusen beliebigen Cod