Java-Sicherheitslücke: Interview mit Entdecker Adam Gowdiak

"Ich habe noch weitere Probleme gefunden."

tecCHANNEL: 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. Jede der Schwachstellen erlaubt es dem Angreifer, die Sandbox der KVM komplett zu verlassen. Mit anderen Worten: Gefährliche Java-Applikationen, die eine der beiden erwähnten Schwachstellen ausnutzen, können den vollen Zugriff auf den Speicher des Geräts und die zu Grunde liegende Funktionalität des Betriebssystems erlangen.

Es bestehen allerdings noch weitere KVM-Komponenten, die 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 Monty VM relevant - das Nokia 6600 nutzt diese VM; die Red.),

  • Die Basisklassen von CLDC und MIDP,

  • Die herstellerspezifischen Klassen (com.symbian.*, com.sun.*, com.nokia., et cetera)

  • Die Implementation nativer Methoden.

Ich habe fast vier Monate mit der Analyse meines Nokia-Handys 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 auf der Betriebssystemebene selbst. Der Speicher (RAM, Flash und I/O-Adressraum) wird global von den unterschiedlichsten Funktionen gemeinsam genutzt (shared memory). Dies bedeutet, dass man, wenn man einmal den Zugang zum Gerät hat, fast alles machen kann!

Ich habe darüber hinaus weitere Probleme gefunden, darf aber derzeit noch nicht darüber sprechen.