Folie: 1

1. JAVA TM Sicherheit Vortragender: Daniel Nowak Folie: 1

2. Ü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

3. 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

4. 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

5. 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 durch Folie: 5

6. 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

7. 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

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

9. Der Class Loader Aufgaben: • Laden,Trennen und Verwalten von Klassen • Einteilung in sicher/unsicher • Schutz der Java System-Klassen Anmerkungen: • Verhindern von Überschreibung vertrauenswürdiger JVM-Klassen durch gleichnamige Klassen von einem Webserver • Erzeugung konkreter Klassen erst nach dem Verifikationsprozess • 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

10. 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

11. 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): Applikation Applet Primordial Class Loader java.lang.ClassLoader java.security.SecureClassLoader java.net.URLClassLoader AppletClassLoader System-Klassen Folie: 11

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

13. Class Loader Regeln Bytecode JVM Class File Verifier Class Internet 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

14. 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

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

16. 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 E x e p t i o n s Folie: 16

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

18. 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

19. 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 JCAundJCE. Folie: 19

20. 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

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

22. 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

23. 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 • Zugriffskontroll- • mechanismen Folie: 23

24. Code Source Signers Bytecode Identity Policy • Access Controller • Stack Inspection Java 2 Sicherheitskonzept Java Runtime 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 Folie: 24

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

26. Sicherheitselemente - Policy • Policy • Zuordnung von Identity und Permissions zu Code (Matrix) (ähnlich dem Security Manager) • Benutzerdefiniert policytool grant CodeBase „http://www.example.com/users/dummy“ , 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:<java_home>/lib/security/java.policy benutzerdefiniert:<user_home>/.java.policy • Spezielle Policy kann bei Applikation angegeben werden: appletviewer -Djava.policy==/home/users/dummy/policy <applet> Folie: 26

27. a.class b.class c.class d.class PD A Permissions PD B Permissions Sicherheitselemente-Protection Domain • 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) Klasse Domain Permission Folie: 31

28. Sicherheitselemente-Secure Class Loader • Secure Class Loader • Implementierung des abstrakten Class Loader • zuständig für das Laden jedenJavacodes(Ausnahme: built-in-Klassen) • insbesondere für das Tracking vonCodeSource und Signatur des mobilen Codes • Applikationen in die Sandbox bringen • CLASSPATH kann beibehalten werden • Applikationen in CLASSPATH werden vom URLClassLoadergeladen !! ...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 Folie: 32

29. Sicherheitselemente-Security Manager • 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 Folie: 33

30. Sicherheitselemente-Access Controller • 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 Folie: 34

31. AccessController.checkPermission() System Domain java.io.FileInputStream() openHighScoreFile() Protection Domain A Stack Stack Inspection - allgemein 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 Folie: 35

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

33. User Code Change Passwort- Applikation Stack Inspection - Beispiel 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(); } Datei öffnen Folie: 37

34. User Code Change Passwort- Applikation Stack Inspection - Beispiel Unsicherer UserCode verwendet vertrauenswürdigen Code. Die Change Passwort-Applikation würde dementsprechend folgenden Code beinhalten: 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... • } Folie: 38

35. Stack Inspection - Algorithmus 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 Folie: 39

36. Access Controller – Security Manager 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 Folie: 40

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