Sicherheit und Zugriffsschutz

Übersicht: Sicherheit und Zugriffsschutz

• Sicherheitskonzept von Java
• Bytecode Verifier
• Zugriffsschutz
• Historie der Sicherheitslücken

• Keine expliziten Pointer.
• Keine Pointerarithmetik.
  
  
• Highlevel Unterstützung zur Bearbeitung von Strings und Arrays. Es besteht also keine Möglichkeit über Pointer die Strukturen zu bearbeiten.
  
  
• Überprüfung der Grenzen von Arrays.
• Ein einmal angelegtes Array kann nicht mehr in der Größe verändert werden.
  
  
• Strings können in Java nicht nachträglich verändert werden.
  
  
• Java ist eine streng getypte Sprache, d.h. Befehle, Methoden können nur mit den korrekten Argumenten ausgeführt werden.
  
  
• Durch das Schlüsselwort final kann verhindert werden, daß eine Variable zur Laufzeit modifiziert wird.
  
  
• Bevor eine Methode ausgeführt wird, wird durch den Compiler geprüft, ob die Typen übereinstimmen.
  
  
• Java bietet vier Stufen des Zugriffs auf Methoden und Variablen in den Klassen:
  • public: Zugriff von überall
  • protected: Zugriff nur von der Subklassen.
  • private: Zugriff nur von innerhalb der Klasse
  • default: Zugriff nur von innerhalb des Pakets

1. Schritt: Überprüft die eigentliche Struktur des Class Files. Die ersten vier Byte müssen die richtige Magicnumber enthalten, alle Attribute müssen die richtige Länge haben und das File darf nicht abgeschnitten oder zu lang sein.

   
   ClassFile {
   	u4 magic;					0xCAFEBABE
   	u2 minor_version				3
   	u2 major_version				45
   	u2 constant_pool_count;
   	cp_info constant_pool [constant_pool_count-1];
   	u2 access_flags;
   	u2 this_class;
   	u2 super_class;
   	u2 interfaces_count;
   	u2 interfaces[interfaces_count];
   	u2 fields_count;
   	field_info fields[fields_count];
   	u2 methods_count;
   	method_info methods[methods_count];
   	u2 attribute_count;
   	attribute_info attributes[attributes_count];
   }
   
   

2. Schritt: Dieser Schritt erfolgt nach dem Linken und überprüft alles, was überprüft werden kann, ohne den Code direkt zu betrachten.
   • Final Klassen dürfen keine Subklassen haben, und final Methoden dürfen nicht überschrieben worden sein.
   • Jede Klasse muß eine Superklasse besitzen.
   • Der Constant Pool muß die statischen Bedingungen erfüllen.
   • Alle Feld- und Methodenreferenzen im Constant Pool müssen gültige Namen, Klassen und Typdescriptoren haben.

3. Schritt: Dieser Abschnitt stellt den eigentlichen Bytecode Verifier dar.

   Erst wird sichergestellt, daß

   • Verzweigungen korrekt sind:
     • nur innerhalb der Methode verzweigt wird.
     • nur an den Anfang von Instruktionen verzweigt wird.
   • alle Zugriffe auf das Array der lokalen Variablen einen gültigen Index haben.
   • alle Referenzen auf den Constant Pool auf den richtigen Typ zeigen.
   • der Code nicht in der Mitte eines Befehls endet.
   • dass für jeden Exceptionhandler korrekt angegeben ist, welchen Codeabschnitt er überwacht.
   
   Danach wird eine Datenfluß-Analyse des Codes der Klasse durchgeführt. Hierzu durchläuft der Bytecode-Verifier den Code und betrachtet für jede Instruktion die Auswirkungen auf den Operanden-Stack und die lokalen Variablen um sicherzustellen, daß für jede Instruktion:
   • Alle Operationscodes die richtige Anzahl von Argumenten passenden Typs auf dem Operanden-Stack und in den lokalen Variablen besitzen.
   • Keine lokale Variable benutzt wird, bevor ihr nicht ein gültiger Wert zugewiesen wurde.
   • Methoden mit den korrekten Argumenten aufgerufen werden.
   • Feldern nur Werte des passenden Typs zugewiesen werden.

4. Schritt: Diese Überprüfungen geschehen erst beim Ausführen des Codes. Wenn das erste mal eine Instruktion ausgeführt wird, die auf einen bestimmten Typ referenziert, wird
   • die Definition des Typs geladen, soweit es noch nicht geschehen ist.
   • Überprüft, ob der aktuelle Typ auf den referenzierten Typ zugreifen darf.
   • die Klasse initialisiert, soweit es noch nicht geschehen ist.
   
   Das erste Mal, wenn eine Methode aufgerufen oder auf ein Feld zugegriffen wird, werden folgende Aktionen ausgeführt:
   • Überprüfen, ob die referenzierte Methode oder Feld in der Klasse existiert.
   • Überprüfen, daß die referenzierte Methode den angezeigten Descriptor hat.
   • Überprüfen, daß die aktuelle Methode auf die referenzierte Methode oder Feld zugreifen darf.

       Variable              Bedeutung
       java.version          Java Versionsnummer
       java.vendor           Java herstellerspez. String
       java.vendor.url       Java Hersteller URL
       java.class.version    Java class version number
       os.name               Betriebssystem Name
       os.arch               Betriebssystem Architecture
       file.separator        File Separator (z.B., "/")
       path.separator        Path Separator (z.B., ":")
       line.separator        Line Separator (z.B., crlf)

       java.home             Java Installation Verzeichnis
       java.class.path       Java Klassenpfad
       user.name             Account Name des Anwenders
       user.home             Homedirectory des Anwenders
       user.dir              aktuelles Arbeitsverzeichnis des Anwenders

Erneuter ClassLoader Angriff (18. Mai 1996)
Es wurde erneut ein Weg gefunden die Restriktionen zu umgehen, um einen eigenen ClassLoader zu erstellen. Dadurch konnten Klassen definiert und ausgeführt werden, die normalerweise nicht ausgeführt worden wären.

Feindliche Applets (April 1996)
Im Web tauchten Seiten mit feindlichen Applets auf, die böswillig Resourcen auf dem Client blockieren.

URL name resolution Angriff (April 1996)
In einer speziellen Firewall-geschützten Netzwerkkonfiguration ist es möglich, daß ein von einem Client innerhalb der Firewall geladenes Applet fähig ist, eine Verbindung zu einem Host außerhalb der Firewall aufzubauen.

Fehler in der Implementierung des Bytecode Verifiers (März 1996)

Fehler in der Implementierung des ClassLoaders (März 1996)
Ein Fehler in der Implementierung des ClassLoaders machte es möglich illegalen Bytecode zu laden, der dann dazu benutzt werden konnte eine Klasse zu laden, die durch einen absoluten Pfad referenziert wurde.

DNS Angriff (Februar 1996)
Angriff auf das Applet Sicherheitsmodell, der darauf basiert, wie der Applet Securitymanager DNS (Domain Name Server) benutzt um Namen IP-Adressen zuzuordnen.