Adam Gowdiak, der Entdecker der Sicherheitslücke in Java-Handys, im Gespräch mit PC-WELT
PC-WELT sprach mit dem Mann, dessen Entdeckung Millionen von Handy-Besitzern den Schlaf raubt.
PC-WELT: Adam, mit welcher Intention haben Sie sich daran gemacht, der Sicherheit von J2ME einmal genauer auf den Grund zu gehen?
Gowdiak: Nun, bislang wurden in Bezug auf die Java-Technologie für mobile Endgeräte (Java 2 Microedition Plattform) keinerlei Sicherheitsprobleme gemeldet. Eine solche Situation ist in der Realität ziemlich unwahrscheinlich und dies trifft insbesondere im Zusammenhang mit solch komplexen Technologien wie Java zu. Die Vergangenheit hat uns immer wieder gezeigt, dass die Java VM-Implementationen diverser Hersteller (Sun Microsystems, Microsoft) so einige Probleme hatten. Vielleicht hat man den Aspekt der J2ME-Sicherheit einfach als gegeben angenommen ohne genauer zu hinterfragen.
Meine Motivation war, dass man einfach davon ausging, dass die Technologie nicht aus den Angeln gehoben werden kann und dies hat kombiniert mit meiner herausfordernden Natur und Intuition eben dazu gehört, die J2ME-Technologie mal etwas genauer unter die Lupe zu nehmen.
PC-WELT: Wie lange hat es gedauert, bis Sie den ersten Ansatz eines Angriffes gefunden hatten?
Gowdiak: Es dauerte zwei Monate um in J2ME einzubrechen und weitere vier Monate um meine Ergebnisse durch das Programmieren von böswilligen Java-Applikationen zu beweisen.
PC-WELT: Sie haben einen Weg über die pre-Verifizierungsebene gefunden um letztendlich den Zugriff zum Handy zu erlangen. Stellten Sie während der Arbeiten noch andere Schwachstellen fest oder hatten Sie einfach einen „guten Tag“ erwischt?
Gowdiak: Mein methodischer Ansatz führte zur Entdeckung zweier unterschiedlicher Schwachstellen in der Komponente des Bytecode-Verifier der KVM – der dedizierten Virtual Machine für kleine, in ihren Ressourcen beschränkte Endgeräte (mobile Telefone, PDAs). Jede der Schwachstellen erlaubt es dem Angreifer, die Sandbox der KVM komplett zu verlassen. In anderen Worten: Gefährliche Java-Applikationen, welche eine der beiden erwähnten Schwachstellen ausnutzen, können den vollen Zugriff auf den Speicher des Gerätes und der zugrunde liegenden Funktionalität des Betriebssystems erlangen.
Es bestehen allerdings noch weitere KVM-Komponenten welche ebenfalls unsicher sind, wobei ich diese bislang noch nicht analysiert habe. Diese schließen ein:
* KVM Runtime (execution engine)
* JIT compiler (derzeit nur für Monthy VM relevant – das Nokia 6600 nutzt diese VM; die Red.)
* Die Basisklassen von CLDC und MIDP
* Herstellerspezifische Klassen (com.symbian.*, com.sun.*, com.nokia., etc.)
* Die Implementation nativer Methoden
* JIT compiler (derzeit nur für Monthy VM relevant – das Nokia 6600 nutzt diese VM; die Red.)
* Die Basisklassen von CLDC und MIDP
* Herstellerspezifische Klassen (com.symbian.*, com.sun.*, com.nokia., etc.)
* Die Implementation nativer Methoden
Ich habe fast vier Monate mit der Analyse meines Nokia-Handies verbracht. Ich fand dabei natürlich eine Menge Details über dessen interne Arbeitsweise und die Architektur des nativen Nokia-Betriebssystems heraus. Das größte Problem fand ich dabei auf der Betriebssystemebene selbst. Der Speicher (RAM, Flash und I/O-Adressraum) wird global von den unterschiedlichsten Funktionen gemeinsam genutzt (shared memory). Dies bedeutet: Hat man einmal den Zugang zum Gerät, kann man fast alles machen!
Ich habe darüber hinaus weitere Probleme gefunden, darf aber derzeit noch nicht darüber sprechen.
Lesen Sie auf der nächsten Seite:
Vorherige Seite
Seite 1 von 3
Nächste Seite
