Folie: 1

JAVA

Sicherheit

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

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

java.net.URLClassLoaderAppletClassLoader

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 Canada

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

spezielle 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

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