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