Daniel Nowak

TM
JAVA
Sicherheit
Vortragender: Daniel Nowak
Folie: 1
Ü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)
•
Zugriffskontrolle
–
•
Stack Inspection
Objekte des neuen Sicherheitskonzeptes





•
policytool
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:
Sicherheitsangriff
Java Sicherheit
Systemmodifikation
Invasion of Privacy
Denial of Service
„Belästigung/Täuschung“
stark
stark
schwach
schwach
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
•
Garbage Collection
•
automatisches Prüfen von Arraylängen
•
strenge Typisierung
•
Zugriffsrechte
•
Exception Handling
•
Objektorientierung(Data-Hiding, Abstaktion,Kapselung)
keine ungültigen Speicherzugriffe
keine illegalen Casts, Objektzugriffe
Einschränkung der Sichtbarkeit von Elementen
Sicherheitsdesign
Aber wichtiger ist die zugrunde liegende JVM !
Portabilität
durch
Java Source Code
Bytecode
Bytecode
Folie: 5
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.
Class Loader
Bytecode
JVM
Internet
Folie: 8
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
Abgeleitete Class Loader(Java2):
Remote-Klassen
Applikation
Applet
Primordial Class Loader
java.lang.ClassLoader
java.security.SecureClassLoader
java.net.URLClassLoader
AppletClassLoader
System-Klassen
Folie: 11
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
Class Loader
Regeln
Bytecode
JVM
Class File
Verifier
Class
Internet
Folie: 13
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?
JVM initiiert
das Laden von
Klassen
PrimordialClass
Loader für SystemKlassen
Applet Class Loader
holt Klassen über
das Netz
Class
File
Verifier
In Java 2 auch Applikationen (URLClassLoader)
Folie: 15
Bytecode-Verifikation
Die 4 Phasen der Verifikation:
–
Datei-Integrität überprüfen
•
–
Klassen-Integrität überprüfen
•
•
–
Superklasse(wenn vorhanden) nicht final
Name und Signatur von Methoden und referenzierten Klassen
Bytecode-Integrität überprüfen
•
•
•
–
Format(0xCAFEBABE),Länge
Datenfluß-Analyse
Stack-Checking
statische Typüberprüfung
Laufzeit-Integrität überprüfen
•
dynamische Typüberprüfungen
Folie: 16
E
x
e
p
t
i
o
n
s
Der Security Manager
Der Security Manager überwacht potentiell gefährliche
Operationen auf dem OS.
mobiler
Code
JVM
Security
Manager
ja
nein
Exception
OS-Calls
Folie: 17
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?
–
–
WAS darf das Programm tun?
–
–
Signaturen, Zertifikate
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.
Provider 3
Provider 2
Algorithmus A
Provider 1
Algorithmus
A
Algorithmus
B
Algorithmus
A
Algorithmus
B
Algorithmus
C
Engine Classes
Signature
KeyPair
User Code
MessageDigest
Algorithmus
B
Algorithmus
C
etc...
Algorithmus C
Folie: 21
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.
Zugriffskontrollmechanismen
4 zentrale Capabilities:
•
•
•
•
fein dosierte Zugriffskontrolle
konfigurierbare Sicherheitspolitik
erweiterbare Zugriffskontrollstruktur
Sicherheitsprüfung für alle Programme
Folie: 23
Java 2 Sicherheitskonzept
Java Runtime
Bytecode Identity
Code Source
Signers
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
Folie: 24
Sicherheitselemente-Identity+Permission
Version von SUN:
–
Identity
»
Basis für sicherheitskritische Entscheidungen
Herkunft
Signatur
java.security.CodeSource
–
URL
public key
Permission
»
»
Kapselung sicherheitskritischer Anfragen(System-Calls)
abstrakt: java.security.Permission
target
action
java.security.Permission
eigene Permissions
FilePermission
SocketPermission
PropertyPermission
RuntimePermission
NetPermission
AWTPermission
Folie: 25
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
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)
a.class
b.class
c.class
d.class
PD A
Permissions
PD B
Permissions
Klasse
Domain
Permission
Folie: 31
Sicherheitselemente-Secure Class Loader
•
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
Folie: 32
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
weiter an Access Controller
z.B.:
public void checkLink(String lib){
checkPermission(new RuntimePermission(„loadLibrary.“+lib);
}
Folie: 33
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
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 MethodenaufrufSequenz bzw. Protection-Domain-Sequenz beschrieben.
Beispiel: Spiele-Applet versucht, eine HighScore-Datei zu öffnen
AccessController.checkPermission()
System Domain
java.io.FileInputStream()
openHighScoreFile()
Stack
Protection Domain A
Folie: 35
Stack Inspection
Problem:
Applikation kann unsicheren Code enthalten.(oder andersherum)
Java Applikation
(z.B. Browser)
untrusted Code
vertrauenswürdig?
Call
Java System Library
Folie: 36
Stack Inspection - Beispiel
Unsicherer UserCode verwendet
vertrauenswürdigen Code.
User Code
Change Passwort- Datei öffnen
Applikation
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();
}
Folie: 37
Stack Inspection - Beispiel
Unsicherer UserCode verwendet
vertrauenswürdigen Code.
User Code
Change Passwort- Datei öffnen
Applikation
Die Change Passwort-Applikation würde dementsprechend folgenden Code
beinhalten:
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
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
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
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:
Security Tutorial von Sun
Folie: 41