Sicherheitskonzepte ausgewählter Systeme
Security-Whitepaper: http://java.sun.com/security/whitepaper.ps
Vorteile der JVM:
- Write once Run everywhere:Nur JVM muß portiert werden. Der Anwendungsentwickler muß sich nicht
um die Portierung seiner Anwendung auf jedes Zielsystem kümmern. (große
Kosteneinsparung)
Applets
Applets sind kleine Javaprogramme, die auf der JVM in einem WWW-Browser laufen.
Gefahrenpotential: Applet könnte Trojanisches Pferd sein und im lokalen Netzwerk Unfug treiben, Informationen auspähen, ...
Sandkasten paradigma: Nicht vertrauenswürdiger Code läuft in einer geschützten
Umgebung ab, wo kein Schaden angerichtet werden kann.
Die JVM muß Schutzumgebung sichern
- Keine lesenden und Schreibenden Zugriffe auf Lokale Platte
- Nur Netzwerkverbindungen zu dem Rechner, wo das Applet herkommt
- Wenn Fenster geöffnet wird, muß dieses betitelt sein, daß es von
einer nicht vertrauenswürdigen Software kommt
Sicherheitsmechanismen, die ein Applet durchlaufen muß:
- (Applet-)Class Loader
wird aufgerufen, wenn Browser Applet aus dem WWW holt.
Die Namensraumhierarchie wird erzwungen. (Der Namensraum legt fest, auf welche Teile der JVM das Applett zugreifen darf.)
Die Applets haben einen anderen Namensraum als Programme, die von der
lokalen Platte stammen.
Applets vom Netz können keine eigene Class-Loader bauen.
Die Applets können auch keine Methoden aus dem System-Classloader aufrufen.
- Verifizierer
wird vor dem ausführen des Applets aufgerufen.
- Entspricht das Applet der Java-Sprach-Spezifikation und
sind da keine Verletzungen der Java-Sprachregeln oder
Namensraumverletzungen ?
- Gibt es irgendwelchen allgemeinen Verletzungen der Speicherverwaltung wie Stack-Over-oder Underflows ?
- Gibt es verbotene Typanpassungen von Daten, die einem fendlichen
Applet erlauben würden, die Sicherheitsmechanismen außer Kraft zu
setzen oder gar Teile des Systemcodes zu ersetzen ?
- Sicherheitsmanager
erzwingt die Grenzen des Sandkastens. Wenn ein Applet irgendeine
gefährliche Operation ausführen will, fragt die JVM den Sicherheitsmanager, ob sie sicher ist. Andernfalls erfolgt der Abbruch und Fehlermedung auf der Javaconsole.
Folgende Operationen wird der Sicherheitsmanager nicht zulassen:
- Lese- oder Schreibzugriffe auf eine Datei
- Löschen einer Datei
- Erlangen von Informationen über eine Datei
- Ausführen von Betriebssystemkommandos oder Maschinencode
- Laden einer Bibliothek
- Aufbauen einer Verbindung zu einem anderen Rechner als dem, wo das
Applett her kommt.
- ...
Es kann für eine Applikation oder für einen WWW-Browser nur einen Security-Manager geben, damit eine einzige Sicherheitspolitik erzwungen wird.
Der Sicherheitsmanager wird zum Start geladen und kann nicht mehr ersetzt werden. Applets können natürlich den Sercuritymanager nicht selber wählen.
- Sprachmerkmale
Die Merkmale schützen die Integität des Sicherheitssystems und verhindern so verschiedene häufige Angriffe:
- keine Zeiger, kein direkter Zugriff auf den physikalischen Speicher
Damit kann kein Programm unbefugt Speicher überschreiben und Systemteile zerstören oder ersetzen.
- Die Sprache überwacht den Typ von neuerzeugten Objekten.
So kann ein Applet nicht seinen eigenen Classloader oder
Security-Manager erzeugen.
- Diverse Prüfungen für Speicher und Zeigermißbrauch, die das Sicherheistsystem Schwächen könnten.
In C++ sind 40-50% aller Fehler durch Fehler in der Speicherverwaltung verursacht. Durch die automatische Speicherverwaltung werden die Programme stabiler und verfügbarer.
Da die Sicherheitspolitik offengelegt ist, kann diese überprüft werden, bevor
Cracker sie entdeckten ...
Weitere Informationen
Erweiterung der Java-Sicherheit
3 mögliche Probleme:
- Spezifikation der Sicherheitsumgebung doch nicht so gut wie angenommen
- Impementierungsfehler, die von Applets ausgenutzt werden können, um auszubrechen
- Unerwartete Interaktionen zwischen Applets und anderen Teilen des netzwerks, die ausgenutzt werden.
http://www.blackwatch.com/ erstellt
unabhängiges Referenzmodell.
Sandkastenparadigma erschlägt nicht alles. Weitere Mechanismen:
- JAR-Dateien mit digitalen Unterschriften
- gegen
- Man-in-the-Middle-Attacks
- Virus-Modifikationen
und hilft bei Caching
- Flexible Politiken
-
- Ein vertrauenswürdiges Bank-Applet soll auch bestimmte lokale Dateien
modifizieren können, PINs verwalten usw.
- Verbindungen zu mehreren Servern kann zugelassen werden.
Der Nutzer soll seine Politik festlegen können.
Nach Security FAQ kann man für den der Appletviewer ACL-Listen in seiner Konfigurationsdatei für Lese- und
Schreibzugriffe spezifizieren.
Netscape hat in Capabilities dies spezifiziert und implementiert.
In jdk1.2.x wurde dieser Mechanismus übernommen ????
- Auditing / Überwachung
- Es wird geloggt, wer wann auf was zugegriffen hat. Damit können Einbrecher
verfolgt werden.
- Verschlüsselung
- Der Datenverkehr zwischen Client und Server muß verschlüsselt werden können.
Erfahrungen
Es gibt seit 1996 bis ??? keine Einträge mehr bei CERT.
Nach BSI sind in WWW-Browsern
immer wieder Sicherheitslücken bekannt geworden, so daß das BSI empfiehlt,
auf aktive WWW-Inhalte zu verzichten.
In letzter Zeit ist das Java-Implementierung berüchtigt von Sicherheitslücken z.B. Heise 5.3.2013. Mache Java-Implementierungen haben sogar die Mechanismen des Betriebssystems deaktiviert! Man hat sich zu sicher gefühlt!
Informatik- und Netzwerkverein Ravensburg e.V
Rudolf Weber