Technische Informatik II Vorlesung 12: Security Peter B. Ladkin Sommersemester 2001 Universität Bielefeld Technische Fakultät.

Präsentation zum Thema: "Technische Informatik II Vorlesung 12: Security Peter B. Ladkin Sommersemester 2001 Universität Bielefeld Technische Fakultät."—  Präsentation transkript:

1 Technische Informatik II Vorlesung 12: Security Peter B. Ladkin ladkin@rvs.uni-bielefeld.de Sommersemester 2001 Universität Bielefeld Technische Fakultät

2 12 June, 2015Technische Informatik II: Vorlesung 122 Sicherheit, Security und Safety  Sicherheit ist ein Wort auf deutsch  Aber dazu korrespondieren zwei Begriffe  Safety  Security  Beide bedeuten die Eigenschaften, die mit Schutz vor einem unerwünschten Erfolg zu tun haben

3 12 June, 2015Technische Informatik II: Vorlesung 123 Safety und Security  Safety  Schutz vor einer unabsichtlichen ungewünschten Wirkung eines Systems  Security  Schutz vor einer absichtlichen ungewünschten Wirkung eines Systems

4 12 June, 2015Technische Informatik II: Vorlesung 124 Ursachen  Man versucht, die Ursachen herauszufinden  Die Ursachen könnten in einer Kausalitäts- "Kette" ausgelegt werden  Allerdings ist es keine Kette. Es ist ein Graph von kausalen Faktoren und ihre Zusammenwirkung  Es gibt mehrere notwendige Ursachen, die zusammen eine hinreichende Ursachenmenge machen

5 12 June, 2015Technische Informatik II: Vorlesung 125 Ursachen  "Notwendig" heisst: Wenn man eine Einzelursache "herausnimmt", hätte der Fall nicht passiert  "Hinreichend" heisst: Wenn alle Ursachen zusammen anwesend sind, passiert unvermeidlich der Fall  Also hat man eine hinreichende Menge von notwendigen Ursachen, sogenannte "INUS" Konditionen (Mackie, The Cement of the Universe, Oxford U. Press, 1974)

6 12 June, 2015Technische Informatik II: Vorlesung 126 Der Unterschied in der Prophylaxis  Safety  Analyziert man die Ursachen für einen Fall, nimmt man Massnahmen gegen eine Ursache, dann kann der Fall auf dieser Art nicht mehr passieren  Security  Problemverhalten sind ziel-orientiert. Wenn man eine von den Ursachen vermeidet, wird ein Ersatz schnell gefunden. Also muss passende Massnahmen übergreiflicher sein

7 12 June, 2015Technische Informatik II: Vorlesung 127 Beispiel  Das Unix-Befehl " rm * " ist gefährlich. Es löscht aller Dateien in dem aktuellen Verzeichnis  Safetymassnahme  rm zu programmieren, um eine Bestätigungsfrage an den stdout zu drucken, und nach Eingabe von "yes" zu löschen bzw. von "no" abzubrechen  Securitymassnahme  rm zu programmieren, um eine Passwort anzufragen, und nach Eingabe des richtigen zu löschen, bzw. nach falscher Eingabe abzubrechen

8 12 June, 2015Technische Informatik II: Vorlesung 128 Umfang einesSecurityproblemes  Einzeloperationen/Befehle  Semantisch korrekt aber Lücken in der Übersetzung in einer Maschine  Buffer Overflow  Höhere Benutzererlaubnis ausserhalb eines Critical Sections  Die Semantik fordert Vertrauen auf den Benutzer  Allgemeines Erlaubnis: "Root Permission"  Änderung der Internet-Parameter (z.B. IP-Adresse) des Rechners  Ermöglicht das Lesen vertraulicher Dateien

9 12 June, 2015Technische Informatik II: Vorlesung 129 Umfang eines Securityproblemes  Umgebung  Was darf Benutzer "Fred" ausführen?  Multi-level Security  "Admin" darf alles  "Fred" darf wenig  "Lucy" darf weniger als Fred  In den sichersten MLS-Betriebssystemen ist es mathematisch bewiesen worden, dass Fred nur kann was er darf  Meistens für die US National Security Agency (NSA) entwickelt worden  Sehr aufwendig

10 12 June, 2015Technische Informatik II: Vorlesung 1210 Erlaubnisse  Was heisst "darf"? Darf was?  Eine Operation ausführen  Ein Datei lesen  Ein Datei schreiben bzw. löschen

11 12 June, 2015Technische Informatik II: Vorlesung 1211 MLS Beispiele  Multics ist nach einem MLS-Modell designt  Unix ist von Bell Labs (Kernighan und Richie) zum Spass entwickelt worden, als Bell Labs von dem Multics-Consortium ausgestiegen sind

12 12 June, 2015Technische Informatik II: Vorlesung 1212 Unix  Drei Klassen von Permissions  Admin ("root") darf alles machen, alles lesen, alles schreiben  Gruppen-Rechte für Mitglieder einer Benutzergruppe  Einzelrechte für Benutzer  "Welt"rechte

13 12 June, 2015Technische Informatik II: Vorlesung 1213 Sicherheitsprobleme: Ein Beispiel  Root darf alles  Also darf root der Password-Datei schreiben  Andere Benutzer dürfen nicht das Password-Datei schreiben  Alle Benutzer dürfen das Password-Datei lesen  Benutzere identifieren sich bei der Ausführung des "login"-Programmes. Login muss der Passwort-Datei lesen können, um den Benutzer identifizieren zu können  Also muss die Passwörter in dem Datei verschlüsselt werden; login verschlüsselt das eingegeben Passwort zuerst; danach vergleicht er die beide Verschlüsselungen  So far so good

14 12 June, 2015Technische Informatik II: Vorlesung 1214 Ein Beispiel  Benutzer darf das Passwort-Datei nicht schreiben  Aber man muss die Möglichkeit haben, das Passwort ändern zu können (vielleicht hat ein andere das Passwort beim Eintypen bermerkt)  Darf man aber selbst nicht  Das Kommando muss seine Rechte "höher" setzen, das neue (verschlüsselte) Passwort in das Passwort-Datei hereinschreiben, und die Rechte wieder "niedrig" setzen

15 12 June, 2015Technische Informatik II: Vorlesung 1215 Ein Beispiel  Es gibt ein Befehl, das die Rechte umsetzt  Es heisst "setuid(-)"  Also "setuid(root) wird ausgeführt, das PW- Datei geschrieben, und "setuid(Benutzer)" gemacht  Problem: Was passiert, wenn der ausführende Benutzer schafft, das Programm nach dem "setuid(root)" zu halten und Einzelkommandos von der Tastatur einzugeben? Er hat "root permission". Er kann alles (meistens ist es ein Männliche!)

16 12 June, 2015Technische Informatik II: Vorlesung 1216 Ein Beispiel  Also kann die Interaktion zwischen Umgebung und Einzelkommandos zu solchen Sicherheitslücken führen  Unix ist nicht Multi-level Secure!  Für die Geschichte und die Entwicklung der Ideen von Sicherheit (u.a. MLS), siehe  Donald MacKenzie, Mechanizing Proof, MIT Press 2001

17 12 June, 2015Technische Informatik II: Vorlesung 1217 Umgebungsprobleme  Ausserdem gibt es "Covert Channels"  Ein Benutzer darf u.a., Dateien lesen, von denen er logischerweise Informationen schliessen kann, die er nicht erlaubt ist, zu bekommen  Beispiel:  Es sollte vertraulich bleiben, dass bestimmte Benutzerklassen überhaupt existieren  Fred glaubt, er ist in der höhsten Klasse ausser Admin  Er bemerkt, dass Admin nicht eingelogt ist  Er bemerkt, dass Aktivitäten durchgeführt werden, dass er nicht bestimmen kann  Allerdings liegen sie in eine höheren Klasse als er; allerdings weiss er jetzt, dass es Benutzer gibt, die höhere als er sind aber nicht Admin sind

18 12 June, 2015Technische Informatik II: Vorlesung 1218 Probleme so weit  Kommandos  Probleme mit  Ausführung  Design  Falsche Vertrauen auf Benutzer  Umgebung  MLS  Ungünstige Interaktion zwischen MLS und Einzelkommandos  Covert Channels

19 12 June, 2015Technische Informatik II: Vorlesung 1219 Weitere Probleme  Probleme liegen auch mit den Netzprotokollen  Bestätigungen bzw. ausgeführten Services auf Vertrauensbasis behandelt  Zwei "Exploit"-Arten  "Remote Exploits" benutzen die Protokollsschwäche, um an den Rechner anzukommen (Benutzerrechte auszuüben)  "Local Exploits" sind wie schon für einen berechtigten Benutzer beschrieben

20 12 June, 2015Technische Informatik II: Vorlesung 1220 Local Exploits  Man bekommt zuerst Benutzername+Passwort  Man logt sich mit diesen beiden ein  Man macht Mist (schriebt Files, löscht Files, versucht root-Rechte zu bekommen)

21 12 June, 2015Technische Informatik II: Vorlesung 1221 Local Exploits  Wie bekommt man BN+PW?  Man liesst Protokollverkehr auf das Kabel bzw. in einem Rechner, die die Pakete überträgt  Bei bestimmten Services laufen BN+PN in Klartext (telnet, ftp, pop, imap)  z.B. Man hängt sein Laptop auf ein Ethernet und liesst die IP-Pakete, die hin und her geschickt werden  Gegenmassnahme1: man kann es nicht., z.B. Switched Verkehr, der nur zwischen Quelle und Ziel läuft  Gegenmassnahme 2: man erlaubt nur vertraute Benutzer an dem physikalischen Netz daran  Gegenmassnahme 3: man verschlüsselt der Verkehr

22 12 June, 2015Technische Informatik II: Vorlesung 1222 Local Exploits  Probleme  Gegenmassnahme 1: wenn man ein Switch mit vielen Paketen gleichzeitig überlastet, macht der Switch Broadcasting, bis der Verkehr wieder vernünftig ist  Gegenmassnahme 2: die Putzleute haben auch meistens Schlüssel sowie auch Freunde  Gegenmassnahme 3: Die Verschlüsselung muss hinreichend sein. Z.B., bei einem FunkLAN nach IEEE 802.11 ist die Verschlüsselung nicht hinreichend

23 12 June, 2015Technische Informatik II: Vorlesung 1223 Die beste Massnahme  Ständige oder frequente Überwachung  Logfiles von Service-Benutzung  Unpassende Einträge bemerken und nachfolgen  Angucken, wenn verdächtige Operationen ausgeführt werden  Services abschliessen, wenn man sicher ist, man weiss was gemacht worden ist und deswegen wo Befehle für die Benutzung des Crackers gespeichert sind  Aufräumen oder das System wieder von Backup hinstellen und Benutzer anfordern, BN+PW zu ändern  Mit Passwort-Verfahren endlich aufhören!

24 12 June, 2015Technische Informatik II: Vorlesung 1224 Stichwörte  Sicherheit ist relativ  Ziel: besser als die Nachbarn zu sein und wenig attraktiv  Sicherheit ist nur relative  Ausserhalb des NSAs gibt es keinen wirklich sicheren Rechner  Überwachung ist wesentlich