Folie: 1 JAVA Sicherheit TM Vortragender: Daniel Nowak

Übersicht Das Basis-Sicherheitskonzept der Java Virtual Machine Sandbox Der Class Loader Der Class File Verifier Der Security Manager Neue Sicherheitsmechanismen in Java 2 Sicherheitsstrategien( Policy) policytool Zugriffskontrolle – Stack Inspection Objekte des neuen Sicherheitskonzeptes Identity Permission Access Contoller Protection Domain Policy Cryptografie Folie: 2

Motivation höchst populäre Entwicklungsplattform mobiler Code -dynamischer Download Komponenten-basiert... wichtig für e-Commerce Millionen Internetnutzer (Netscape Navigator, Internet Explorer) Browser bringen ihre eigene VM mit Javas Portabilität erlaubt es, Applets an Webpages anzuhängen...und Entwickler von Java-Programmen Java bietet viel bezüglich Sicherheit: Crypto APIs Sicherheitsmechanismen in der Sprache/Architektur schwierig, unsicheren Code zu schreiben...das heißt aber nicht, sichere Programmentwicklung in Java ist trivial Folie: 3

Gefahrenquelle: ausführbarer Code 4 Klassen von Sicherheitsangriffen: Java dämmt diese Gefahr ein durch: JVM lässt den Code nur in abgesichertem Bereich laufen („Sandbox“) strikte Zugriffskontrolle auf das umgebene System Bytecode wahrt das Sandbox-Prinzip Programmiersprache Folie: 4

Java als Sprache Java als Sprache scheint wichtig zu sein: keine Pointer-Arithmetik keine ungültigen Speicherzugriffe Garbage Collection automatisches Prüfen von Arraylängen strenge Typisierung keine illegalen Casts, Objektzugriffe Zugriffsrechte Einschränkung der Sichtbarkeit von Elementen Exception Handling Objektorientierung(Data-Hiding, Abstaktion,Kapselung) Sicherheitsdesign Aber wichtiger ist die zugrunde liegende JVM ! Portabilität Bytecode Java Source Code Bytecode Folie: 5 durch

Das Basis-Sicherheitskonzept der JVM Konzept der sicheren Sandbox für Java-Programme Die Sandbox wird durch 3 eng zusammenwirkende Teile realisiert: – Class Loader separiert geladene von lokalen Klassen – Class File Verifier Verifikation aller Klassen, die in die Sandbox geladen werden  v.a. Gewährleistung der Typsicherheit – Security Manager überprüft (Datei-,...)Zugriffsversuche außerhalb der Sandbox zur Laufzeit Folie: 6

Die Sandbox-Restriktionen Was soll verhindert werden? – Veränderungen am Browsersystem(z.B. durch Systemaufrufe, Dateiupdates) – lokaler Speicherzugriff: unerlaubtes Lesen/Schreiben von Dateien,Umgebungsvariablen Löschen, Anlegen von Dateien/Verzeichnissen Auslesen von Verzeichnissen – Aufbau von Netzwerkverbindungen(„phone home“-Regel) – Portlistening – System-Properties auslesen/setzen (user.name...) – willkürliche Programmausführung(Runtime.exec()) – Terminierung des Java Interpreters – Dynamisches Laden von Libraries – Manipulation von Threads – Installieren eigener Class Loader, Security Manager – Überschreiben oder Korruption von System-Klassen Folie: 7

Der Class Loader...ist dafür verantwortlich, alle verschiedenen Teile eines Programmes zusammenzubringen, damit es ausführbar ist. Folie: 8 JVM Bytecode Internet Class Loader

Der Class Loader Aufgaben: – Laden,Trennen und Verwalten von Klassen  Einteilung in sicher/unsicher – Schutz der Java System-Klassen Anmerkungen: o Verhindern von Überschreibung vertrauenswürdiger JVM-Klassen durch gleichnamige Klassen von einem Webserver o Erzeugung konkreter Klassen erst nach dem Verifikationsprozess o Zugriffsrechte auf Elemente innerhalb der Systemklassen-Packages ( java.* ) müssen geschützt werden(Sichtbarkeitsbeschränkungen)  Eigene Klassen dürfen deshalb nicht diesen Packages hinzugefügt werden. Folie: 9

Class Loader Implementierungen 1 eingebauter Class Loader (Primordial Class Loader), der für das Laden der System-Klassen verantwortlich ist meist in C geschrieben volle Rechtevergabe an geladene Klassen es kann bel. viele zusätzliche Class Loader geben für Web-Browser z.B. gibt es den Applet Class Loader für jeden zusätzlichen ClassLoader kann es mehrere Instanzen geben – eine pro Codebase damit: » eigene Namespaces » keine Namenskollisionen » keine Sichtbarkeit zwischen Namespaces Folie: 10

Class Loader Hierarchie Bei der Suche nach Klassen wird eine Class Loader-Hierarchie durchlaufen: direkte Kommunikation zwischen Class Loadern Suchreihenfolge: System-Klassen lokale Klassen Remote-Klassen Abgeleitete Class Loader (Java2) : Folie: 11 Primordial Class Loader java.lang.ClassLoader java.security.SecureClassLoader java.net.URLClassLoader AppletClassLoader Applikation Applet System-Klassen

Class Loader Interaktion Ablauf für das Laden einer Klasse über das Netz: 1 verantwortlicher AppletClassLoader wird kontaktiert 2 lokaler Cache des AppletClassLoaders wird durchsucht 3 Anfrage an Primordial ClassLoader 4 Laden der Klasse vom Host Folie: 12

Der Class File Verifier...prüft, ob das Programm nach den Regeln der JVM läuft das bedeutet nicht unbedingt, dass das Programm die Regeln von Java als Sprache befolgt Folie: 13 JVM Bytecode Regeln Class File Verifier Internet Class Class Loader

Java Bytecode...ist die Maschinensprache der JVM. Beibehaltung des oo-Konzepts Sicherheitstechnische Aspekte für die Verifikation von Bytecode: korrupter Java Cross-Compiler generiert Bytecode aus unsicherer Sprache (Cobol,Delphie) Umgehung des Java Sicherheitskonzepts Folie: 14

Aktivierung des Class File Verifier Wann wird der Class File Verifier benötigt? Folie: 15 JVM initiiert das Laden von Klassen PrimordialClass Loader für System- Klassen Applet Class Loader holt Klassen über das Netz Class File Verifier In Java 2 auch Applikationen (URLClassLoader)

Bytecode-Verifikation Die 4 Phasen der Verifikation: – Datei-Integrität überprüfen Format(0xCAFEBABE),Länge – Klassen-Integrität überprüfen Superklasse(wenn vorhanden) nicht final Name und Signatur von Methoden und referenzierten Klassen – Bytecode-Integrität überprüfen Datenfluß-Analyse Stack-Checking statische Typüberprüfung – Laufzeit-Integrität überprüfen dynamische Typüberprüfungen Folie: 16 ExeptionsExeptions

Security Manager JVM Der Security Manager Folie: 17 mobiler Code OS-Calls ja nein Exception Der Security Manager überwacht potentiell gefährliche Operationen auf dem OS.

Der Security Manager Ursprüngliches Konzept in Java 1.1: definiert check-Methoden, die kritische Aktionen überwachen - z.B. checkRead, checkAccess, checkExit, checkConnect - insg. 29 Methoden Applikationen bringen meist eigene Implementierung des Security Manager mit. - fein-körnige Kontrolle möglich, aber umständlich (besser:Java2) Für Applets gilt der Security Manager des Browsers. -...ist für die Sandbox-Restriktionen verantwortlich Jede laufende JVM hat max. 1 Security Manager! - kann nicht ausgetauscht werden! enge Kooperation zwischen Security Manager und Class Loader Folie: 18

Erweiterung des Sicherheitsmodells zu klärende Anforderungen: – WOHER kommt der Java-Code bzw. WEM kann ich trauen? – Signaturen, Zertifikate – WAS darf das Programm tun? – Permissions (bzw.Rechte) – WIE kann ich die Vertraulichkeit der Daten sichern, die mein Applet verarbeitet? Die Antwort hierauf ist Cryptographie....in Java gibt es hierzu die APIs JCA und JCE. Folie: 19

Sicherheit auf API-Level Java Cryptographie Architecture (JCA 1.2) -- im JDK enthalten besteht aus 5 Packages: – java.security – java.security.acl – java.security.interfaces – java.security.spec – java.security.cert Java Cryptographie Extension (JCE) -- nur für US und Canada java.crypto.* - Standardisierung von sicheren Streams, Key-Generatoren, Cipher Support Folie: 20

Java Cryptographie Architecture flexibles Framework: Verschiedene Provider können ihre eigenen Implementationen der Cryptographie-Tools und anderer administrativer Funktionen anbieten. Folie: 21 Provider 3 Algorithmus A Algorithmus B Algorithmus C Provider 2 Algorithmus A Algorithmus B Algorithmus C Provider 1 Algorithmus A Algorithmus B Algorithmus C Engine Classes Signature KeyPair MessageDigest etc... User Code

Rechtevergabe Frage: Was darf ein fremdes Programm auf meinem System tun? 2 Ansätze: – JDK1.1 Schwarz-Weiß-Prinzip (Sandbox) vertrauenswürdig -- nicht vertrauenswürdig – Java 2 Graustufen-Prinzip dosierbare Vergabe von Rechten flexibel z.B. Satz von Rechten für Videokonferenz-Applets Folie: 22

Java 2 Grundidee: Jeder Code läuft unter einer Sicherheitspolitik, welche Programmen verschiedene Rechte zuordnet! wichtiger Punkt in Java 2-Sicherheitsmodell: Code-Signatur Signaturen allein lassen aber keine graduelle Entscheidungen über Rechtevergabe für Programme zu. 4 zentrale Capabilities: fein dosierte Zugriffskontrolle konfigurierbare Sicherheitspolitik erweiterbare Zugriffskontrollstruktur Sicherheitsprüfung für alle Programme Folie: 23 Zugriffskontroll- mechanismen

Java 2 Sicherheitskonzept Folie: 24 Code Source Signers Bytecode Identity Java Runtime Policy Access Controller " Stack Inspection Grundstein für Java2 Sicherheit: policy (java.security.Policy) Ausführbarer Code wird durch seine Herkunfts-URL und Signatur kategorisiert. Solchen (URL,Signatur)-Paaren werden dann Zugriffsrechte zugeordnet

Sicherheitselemente- Identity+Permission Folie: 25 Version von SUN: – Identity » Basis für sicherheitskritische Entscheidungen – Permission » Kapselung sicherheitskritischer Anfragen(System-Calls) » abstrakt: java.security.Permission Herkunft Signatur java.security.CodeSource URL public key FilePermission SocketPermission PropertyPermission RuntimePermission NetPermission AWTPermission target action java.security.Permission eigene Permissions

Sicherheitselemente - Policy Folie: 26 – Policy » Zuordnung von Identity und Permissions zu Code (Matrix) (ähnlich dem Security Manager) » Benutzerdefiniert policytoolpolicytool grant CodeBase „ SignedBy „*“ { permissions java.io.FilePermission „read,write“, „/applets/tmp/*“; permissions java.net.SocketPermission „connect“, „*.example.com“; }; » Laufzeit-Repräsentation: java.security.Policy » Default-Policy = Sandbox » Plaintext in policy-Datei: default: /lib/security/java.policy benutzerdefiniert: /.java.policy » Spezielle Policy kann bei Applikation angegeben werden: appletviewer -Djava.policy==/home/users/dummy/policy

Policytool Folie: 27 …die Standard-Policy und ihre Einträge in übersichtlicher Form

Policytool Folie: 28 …ein grant-Eintrag mit den zugewiesenen Rechten (Permissions)

Policytool Folie: 29 …hier können bestimmte Rechte benutzerfreundlich vergeben werden

Policytool Folie: 30 zurück …ein Beispiel für einen Permissons-Eintrag: Hier wird eine willkürliche Netzwerkverbindung mit allen Rechten (accept, connect, listen, resolve) gewährt.

Sicherheitselemente- Protection Domain Folie: 31 – Protection Domain logisches Konstrukt zur Gruppierung von Objekten Objekte sind eindeutig Protection Domains(PD) zugeordnet Class Loader Konzept spezielle Domain: System Domain für System-Klassen(haben alle Rechte) a.class b.class c.class d.class PD A PD B Permissions KlasseDomainPermission

Sicherheitselemente- Secure Class Loader Folie: 32 Secure Class Loader – Implementierung des abstrakten Class Loader – zuständig für das Laden jeden Javacodes(Ausnahme: built-in-Klassen) » insbesondere für das Tracking von CodeSource und Signatur des mobilen Codes Applikationen in die Sandbox bringen – CLASSPATH kann beibehalten werden – Applikationen in CLASSPATH werden vom URLClassLoader geladen !!...und sind damit Gegenstand von Sicherheitsüberprüfungen – für System-Klassen gibt es ab JDK 1.2 einen neuen Pfad: Xbootclasspath...und werden mit dem Primordial ClassLoader geladen

Sicherheitselemente- Security Manager Folie: 33 – Security Manager » kann zur Laufzeit ausgetauscht werden! » Sicherheitsüberprüfung bei Instanziierung und Installation: RuntimePermission(„createSecurityManager“) RuntimePermission(„setSecurityManager“) » definiert ein allgemeines Interface für Sicherheitsüberprüfungen » alle check-Methoden durch checkPermission ersetzt bzw. neu implementiert z.B.: public void checkLink(String lib){ checkPermission(new RuntimePermission(„loadLibrary.“+lib); } weiter an Access Controller

Sicherheitselemente- Access Controller Folie: 34 –Access Controller  (final) java.security.AccessController eigentliche Sicherheitsüberprüfung Unter welchen Umständen ist eine Anfrage (nicht)erlaubt? Implementierung des Stack Inspection Algorithmus  Der Access Controller ist für die Zugriffsauthorisierung vor jedem sicherheitskritischen Zugriff verantwortlich  Eine Klasse kann auch dynamisch Stack Ins. initiieren: checkPermission(Permission p) Der Access Controller führt dann die entsprechende Stack Ins.(checkPrivilege()) durch und liefert eine Entscheidung: - AccessControlException Zugriff erlaubt

Stack Inspection - allgemein Folie: 35 Zu klären: Wer darf welche kritischen Aktionen ausführen? Kontext: Thread Jeder Ausführungsthread hat einen eigenen Laufzeit-Stack. Jeder Stack besteht aus Frames. Jeder Frame besteht aus Methodenaufruf(Klasse) + Protection Domain Der aktuelle Kontext wird vollkommen durch die aktuelle Methodenaufruf- Sequenz bzw. Protection-Domain-Sequenz beschrieben. Beispiel: Spiele-Applet versucht, eine HighScore-Datei zu öffnen openHighScoreFile() java.io.FileInputStream () AccessController.checkPermission() Stack System Domain Protection Domain A

Stack Inspection Folie: 36 Problem: Applikation kann unsicheren Code enthalten.(oder andersherum) Java Applikation untrusted Code Java System Library Call vertrauenswürdig? (z.B. Browser)

Stack Inspection - Beispiel Folie: 37 Unsicherer UserCode verwendet vertrauenswürdigen Code. Wie funktioniert das? AccessController bietet hierfür die Methode doPrivileged(). Damit wird der JRE signalisiert, dass der Status der aufrufenen Klasse(Methode) zu ignorieren ist. Idee: Kapselung sicherheitskritischer Operationen in kleinstmögliche Blöcke. Java wrappt den gesamten enable/disable-Prozeß in ein Interface,das mit dem AccessController angesprochen werden kann: interface PrivilegedAction{ Object run(); } User Code Change Passwort- Applikation Datei öffnen

Stack Inspection - Beispiel Folie: 38 Unsicherer UserCode verwendet vertrauenswürdigen Code. Die Change Passwort-Applikation würde dementsprechend folgenden Code beinhalten: User Code Change Passwort- Applikation Datei öffnen public void changePassword(){ //eigene Rechte zum Öffnen der Datei benutzen AccessController.doPrivileged(new PrivilegedAction(){ public Object run(){ //Datei öffnen... return null; } }); //altes und neues Passwort verifizieren... }

Stack Inspection - Algorithmus Folie: 39 checkPrivilege(target){ //loop, newest to oldest stack frame foreach stackFrame{ if(local policy forbids access to target by class executing in stackFrame) throw ForbiddenException ; if(stackFrame has enabled privilege for target) return; if(stackFrame has disabled privilege for target) throw ForbiddenException ; } Stack Ins. Algorithmus, wie er im Access Controller implementiert ist

Access Controller – Security Manager Folie: 40 Access Controler versus Security Manager Access Controller immer installiert -- Sicherheitsüberprüfungen immer gewährleistet Access Controller garantiert Stack Inspection Algorithmus – eigener Security Manager kann u.U. einen korrupten Stack Ins. Algorithmus anbieten doPrivilege() nur in Access Controller unterstützt, nicht unbedingt in Security Manager – dieser Mechanismus könnte also u.U. ignoriert werden

Quellen Bücher: O Securing Java von Gary McGraw, Edward W. Felten O Java Network Security von Robert McGregor et. al. O Inside Java2 Platform Security von Li Gong Webressourcen: Folie: 41 Security Tutorial von Sun