Folie: 1 JAVA Sicherheit TM Vortragender: Daniel Nowak.
-
Upload
jan-steinmann -
Category
Documents
-
view
216 -
download
1
Transcript of Folie: 1 JAVA Sicherheit TM Vortragender: Daniel Nowak.
Folie: 1
JAVASicherheit
TM
Vortragender: Daniel Nowak
ÜbersichtDas 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
Sicherheitsangriff Java SicherheitSystemmodifikation starkInvasion of Privacy starkDenial of Service schwach„Belästigung/Täuschung“ schwach
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 BytecodeJava 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-RestriktionenWas 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 LoaderAufgaben:
– Laden,Trennen und Verwalten von Klassen Einteilung in sicher/unsicher
– Schutz der Java System-KlassenAnmerkungen: 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
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 Loaderjava.lang.ClassLoader
java.security.SecureClassLoaderjava.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
JVMBytecode
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
ClassFile Verifier
In Java 2 auch Applikationen (URLClassLoader)
Bytecode-VerifikationDie 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
Exeptions
SecurityManagerJVM
Der Security Manager
Folie: 17
mobiler Code
OS-Calls
janein Exception
Der Security Manager überwacht potentiell gefährliche Operationen auf dem OS.
Der Security ManagerUrsprü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 Canadajava.crypto.*
- Standardisierung von sicheren Streams, Key-Generatoren, Cipher Support
Folie: 20
Java Cryptographie Architectureflexibles 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 2Grundidee:
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 SourceSigners
Bytecode IdentityJava 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
HerkunftSignatur
java.security.CodeSource
URL
public key
FilePermissionSocketPermissionPropertyPermissionRuntimePermissionNetPermissionAWTPermission
targetaction
java.security.Permission
eigene Permissions
Sicherheitselemente - Policy
Folie: 26
– 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>
Sicherheitselemente-Protection Domain
Folie: 31
– Protection Domain logisches Konstrukt zur Gruppierung von Objekten Objekte sind eindeutig Protection Domains(PD) zugeordnet Class Loader Konzeptspezielle Domain: System Domain für System-Klassen(haben alle Rechte)
a.classb.classc.classd.class
PD A
PD B
Permissions
Permissions
Klasse Domain Permission
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: ThreadJeder 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
Callvertrauenswü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 benutzenAccessController.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 frameforeach 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: Securing Java von Gary McGraw, Edward W. Felten Java Network Security von Robert McGregor et. al. Inside Java2 Platform Security von Li Gong
Webressourcen:
Folie: 41
Security Tutorial von Sun