Mobile Code Security

Im Rahmen des Seminars Web Security

Andreas Marx

WIF 02 98

Inhalt

w Mobile Code

w Schutzmöglichkeiten und -konzepte

w Browser-Integration

w Java

w ActiveX

w JavaScript & Co.

w Ausblick / Diskussion

Mobile Code

w Wird bei Bedarf aus dem Web heruntergeladen

w Ist ausführbarer Inhalt (z. B. Programmcode)

w Client-seitig, z.B. Java Applets, ActiveX Controls, JavaScript, Visual Basic Script, Safe-Tcl, Telescript

w Server-seitig, z.B. Servlets

w Problem: Sicherheit (u. a. Integrität, Vertraulichkeit)?!?

Schutzmöglichkeiten

w Alles abschalten!

n Am wirkungsvollsten, aber nicht der Sinn der Sache

n (Noch unbekannte) Sicherheitslücken?

n Ist wirklich alles abgeschaltet?

w Digitale Zertifikate

n Kennzeichnen nachvollziehbar den Herausgeber

n Aber wer ist vertrauenswürdig?

w Sandbox:

n Gesicherte Umgebung mit sehr eingeschränkten oder gar keinen Zugriff auf Ressourcen

w (Ständige) Überwachung:

n Komplex und Zeitintensiv

n In Praxis kaum verbreitet

Schutzkonzepte

w Zugriffsschutz auf Systemressourcen

n Im Laufzeitsystem implementiert

n Z. B. Speicherzugriffe nur im eigenen Adressbereich

w Konzeptioneller Ressourcenzugriffsschutz

n Bei Zugriff auf Ressourcen anderer Rechner

n Explizite Aufrufe, d. h. einfach zu überwachen

n Z. B. Datenbanken

w Systemressourcenverbrauchskontrolle

n Zeitintensive Überwachung

n Alle Änderungen am Systemzustand werden überwacht, Transaktionen

n Abbruch, wenn Ressourcen zu lange beansprucht werden

w Konzeptionelle Ressourcenverbrauchskontrolle

n Kombinierbar mit Zugriffskontrolle in Abhängigkeit vom Systemzustand (z. B. Auslastung)

n Nur bestimmte Anzahl von DB-Zugriffen bei gewisser Auslastung zulassen

Browser-Integration

w Hilfsprogramme bzw. Plug-Ins

n Kommen bei nicht (direkt) vom Browser unterstützten Dateiformaten zum Einsatz

l Z. B. AVI, MPG, MP3, RM, PDF

n Sind in der Regel schon vorher installiert

n Keine Ausführungsbeschränkungen oder Prüfungen

n Vertrauenswürdige Herkunft, Originale

n Z. T. aber auch Zugriffsschutzmodelle (kaum relevant)

Java

w Ursprung: Oak (1991)

w Durchbruch mittels WWW als Java (1994)

w Designziele: Plattform-unabhängig, Kompakt, Verfügbar, über das Netz herunterladbar

w Als Programm oder im Browser startbar

w Bytecode, wird interpretiert (langsam) oder per Just-in-Time-Compiler (JIT) direkt in Maschinencode übersetzt

w JDK 1.0.x:

n Lokale Programme haben Vollzugriff

n Mobile Code läuft nur in der Sandbox

w JDK 1.1.x:

n Einführung von digitalen Signaturen

n Mobilen Code kann man auch Vollzugriff ermöglich

w JDK 1.2.x:

n Feinere Zugriffsrechte definierbar

w Laden von Java Applets im Browser:

n Bytecode Verifier

n Applet Class Loader

n Applet (in eigenem Namespace)

n Ausführung in der Java Virtual Machine

n Überwachung durch den Security Manager

n Datenaustausch nur mit Herkunftsseite möglich

w Probleme: u.a. Sicherheitslücken (insbesondere in frühen Versionen) und in „MS-Java“

ActiveX

w Microsoft‘s Ansatz von mobilen Anwendungen

w Sammlung von Technologien, Protokollen und APIs, um ausführbaren Code über das Internet zu laden

w Ursprung: OCX-Controls zur „nahtlosen“ Integration von Desktop und Netzwerk

w Nur für Windows-Plattformen (Intel, 32 Bit)

w Nicht auf Sicherheit ausgelegt, sondern dies wurde erst per Authenticode „drumherumgebaut“

w Arten von ActiveX-Controls:

n Native Code: Am gefährlichsten, direkt ausführbar, „Vollzugriff“ auf den Rechner

n Java Bytecode: Für JVM (Sandbox oder privilegiert), Überwachung möglich

n Mischform: Genauso gefährlich wie Native Code

w Authenticode:

n Digitale Signaturen (Public-Key-Zertifikate)

n Prüfung der Signatur beim Herunterladen des Controls (z.B. Unversehrtheit, Gültigkeit)

n Individuelle Entscheidung des Benutzers bei jedem ActiveX-Control (einzeln wählbar), ob er es ausführen möchte oder nicht

w Gefahren: Keinerlei Beschränkungen, häufige Sicherheitslücken

JavaScript & Co.

w JavaScript: Von Netscape entwickelt (LiveScript)

w JScript: Microsofts Implementierung von JavaScript

w Visual Basic Script: Microsoft‘s eigene Skriptsprache

w Prozeduraler Aufbau (mit Parametern)

w Werden interpretiert

w Keine Klassen (Objekte) erzeugbar, aber auf vorhandene kann zugegriffen werden

w Kann zwar nicht auf Dateien zugreifen, dafür aber auf andere Elemente (z.B. History, URLs)

w Keine unterschiedlichen Sicherheitsrichtlinien für einzelne Skripte einer Webseite möglich, entweder alles oder nichts

w Gefahren: DoS-Attacken (Fenster öffnen, Endlosschleifen), Generierung von anderem Code (Skripte oder Java), Web-Spoofing

Ausblick / Diskussion

w Die Zukunft ist voller Überraschungen...

w Was ist nun die „beste Möglichkeit“ für Mobile Codes, wie müsste sie aussehen und wie wäre sie zu implementieren?

w Ist so etwas überhaupt realisierbar?