daily.out

2008-09-18

Unvollendet: The Month of Apple Bugs

Sie wollten jeden Tag im Monat Januar 2007 neue Fehler bekanntmachen und zeigen, wie man sie ausnutzen kann. Fehler in Mac OS X oder in Programmen, die darauf laufen.

Kein Programm kann ab einer bestimmten Größe fehlerlos sein. Wollten sie also eine Selbstverständlichkeit nachweisen?

Wie sie selbst schreiben, ging es ihnen darum, die Sicherheit von Mac OS X zu erhöhen, indem sie sicherheitsrelevante Fehler finden und veröffentlichen. Als positive Nebenwirkungen erwarteten sie eine Sensibilisierung der Benutzer-Basis und eine bessere Fehlerverwaltung durch Apple, obwohl viele Fehler anderer Hersteller während dieses Aktions-Monates gezeigt wurden.

Außerdem wollten sie Werkzeuge und dokumentierte Techniken entwickeln und anbieten, um Sicherheits-Untersuchungen auf dieser Plattform zu unterstützen. Im Endeffekt haben sie jedoch bekannte und schon Jahre zuvor übliche Techniken eingesetzt, um Schwachstellen aufzuspüren und sie dann auszunutzen.

Man kann Fehler nie ausschließen, aber man kann mit einer anständigen Architektur die Ausnutzbarkeit von sicherheitsrelevanten Fehlern einschränken. So war es auch ihnen nicht vergönnt, das System per Netzwerk ohne Zutun der Benutzer übernehmen zu können durch irgendeinen Bug. Diese Art Fehlerausnutzung war lange Zeit auf einer anderen Plattform möglich.

Deswegen war ich auch sehr gespannt, ob sie einen angekündigten Fehlerbericht mit Inhalt füllen würden: Für den letzten Tag, den 31. Januar hatten sie sich wieder eine offizielle Bug-Nummer reserviert: "CVE-2007-0586" und diese beschrieben mit:

Was auf deutsch soviel bedeutet wie:

Also Spaß über das Netzwerk mit dem Kern; das würde bedeuten: Volle Kontrolle über das System per Netzwerk ohne Zutun der Benutzer. Das wären wirklich Nachrichten.

Allerdings hatte mich das etwas gewundert, denn der Mach-Anteil des Kerns hat keine Netzwerk-Aufgabe in diesem System und die BSD-Komponenten des Kerns, die für Netzwerk zuständig sind, werden auch bei anderen BSD-Systemen eingesetzt. Ein derartiger Fehler darin wäre daher wahrscheinlich schon längst aufgefallen.

Vielleicht findet man ja auf der dedizierten Seite für diesen angekündigten Fehlerbericht mehr? Dort schrieben sie:

Was übersetzt soviel bedeutet wie:

Wenn man bedenkt, daß der Quelltext des Kerns von Mac OS X öffentlich zugänglich und die Sicherheits-Architektur frei dokumentiert ist, dann ist die Korrektheit der obigen Aussage allein davon abhängig, ob der Terminator lesen kann.

Aber ich könnte mich mit meiner Einschätzung ja irren. Vielleicht bringen sie ja diesen Fehler noch später, denn sie schrieben ja "bald". Nach 19 Monaten war ich dann der Meinung, daß dieser Zeitraum des Wartens für "bald" nun lange genug wäre und habe bei ihnen nachgefragt, ob noch etwas kommt:

Auf deutsch:

Als Antwort kam:

Auf deutsch:

Das bedeutet dann in der Kurzfassung: Heiße Luft und starker Abgang.

Nachtrag

Als ich wenige Tage später nochmal auf ihrer Seite nachsah, war seine Email-Adresse dort nicht mehr vorhanden. Ob er Angst vor ähnlichen Nachfragen durch andere hatte?

Apropos Angst: Auf ihrer Startseite gibt es ein Bild, das Rotkäppchen neben einer Überwachungskamera und diesem Spruch zeigt: "Fear makes the wolf look bigger.", was auf deutsch heißt "Angst läßt den Wolf größer erscheinen". War es das, was sie erreichen wollten: Angst unter Mac-Benutzern zu verbreiten?

2008-09-13

Webserver-Einstellung nach Drüberinstallation von Leopard korrigieren

In der Regel wird man Leopard einfach über Tiger drüberinstallieren. Danach sollte man jedoch mindestens zwei Dinge korrigieren:

• Die Leopard-Gruppen, weil diese nicht mit den alten Gruppen aus Tiger übereinstimmen und man beispielsweise im Finder Probleme bekommen kann damit.
• Die Einstellungen für den Apache Webserver, weil man sonst beim Zugriff auf die Seiten der Benutzer nur die Forbidden 403 Zugriffsverweigerung sieht.

Man geht in das Verzeichnis /etc/apache2/users/ und wird dort nur die Datei Guest.conf sehen mit diesem Inhalt:

<Directory "/Users/Guest/Sites/">
    Options Indexes MultiViews
    AllowOverride None
    Order allow,deny
    Allow from all
</Directory>

Man muß für jeden Benutzer eine entsprechende Datei anlegen, die anstelle von "Guest" den jeweiligen Kurznamen enthält.

Damit die Zugriffsrechte korrekt sind, habe ich die Kopie für mich mit sudo gemacht: sudo cp Guest.conf macmark.conf. In der Datei habe ich dann noch "/Users/Guest/Sites/" durch "/Users/macmark/Sites/" ersetzt.

Um sicherzugehen, daß der Webserver die Änderung bemerkt, sollte man Web Sharing einmal deaktivieren und wieder aktivieren.

2008-09-07

Safari einsperren (aktualisiert 2010-05-15)

Man liest gelegentlich von Fehlern in Safari, die es ermöglichen, mit Hilfe von an diesen Stellen eingeschleusten Programmbefehlen, unerwünschte Dinge zu tun.

Da man nie ausschließen kann, daß doch noch irgendwo im Programm ein Fehler unentdeckt schlummert, läuft man Gefahr, daß dieser irgendwann entdeckt und eventuell sogar ausgenutzt werden kann für unangenehme Dinge. Was man allerdings tun kann ist: Das Programm, in diesem Beispiel Safari, gehörig einzusperren.

Dies ist ein Sandkasten (Sandbox: Sandkästen in Leopard), den ich selbst entwickelt habe und schon ein paar Monate lang einsetze. Ich habe seine Definition als "safari.sb" in einer Textdatei unter /Users/macmark/Documents/safari.sb gespeichert.

Das Semikolon leitet hierbei Kommentarzeilen ein. Ich bin bei der Entwicklung schrittweise vorgegangen, indem ich anfangs alles verboten habe und nach und nach weitere Erlaubnisse hinzugefügt habe, die Safari zum Laufen benötigt inklusive der Orte, an denen er temporäre Dateien anlegt, und der Orte, an denen ich mit Safari Dateien öffnen oder speichern möchte. Wie in Testlauf im Sandkasten beschrieben, kann man sich an vorhandenen Sandkästen orientieren und an den Fehlerausgaben, die man erhält, wenn Safari etwas versucht, was verboten ist. Pro Fehlerausgabe kann man sich dann überlegen, die Aktion als erlaubt in den Sandkasten aufzunehmen oder eben nicht.

Der so eingeschränkte Safari kann unter anderem nicht auf den Schreibtisch schreibend oder lesend zugreifen. Selbst unter root könnte er das nun nicht mehr.

Um Safari per Mausklick mit diesem Sandkasten aufrufen zu können habe ich mir eine Textdatei namens "Safari.command" angelegt, die folgendes enthält:

#!/bin/sh
sandbox-exec -f /Users/macmark/Documents/safari.sb /Applications/Safari.app/Contents/MacOS/Safari &

Ins Dock gezogen startet sie mir Safari innerhalb des definierten Sandkastens mit einem Klick. Hier ist als erster Parameter angegeben, welche Datei den Sandkasten definiert und als zweiter Parameter, welche ausführbare Datei gestartet werden soll.

Die Datei sollte man natürlich vorher noch ausführbar gemacht haben:

KeyWest:~ macmark$ chmod u+x Documents/Safari.command
KeyWest:~ macmark$ ls -al Documents/Safari.command
-rwxr--r--@ 1 macmark staff 110 Jun 11 16:46 Documents/Safari.command

2008-09-07

Root-Shell einsperren

Man kann mit der (Sandbox: Sandkästen in Leopard) Sandkasten-Funktion von Leopard beliebige Grenzen errichten, die nicht einmal Root überschreiten kann. Damit kann man sicherstellen, daß selbst böswillig eingeschleuste Programmbefehle diese zusätzlichen Grenzen nicht überwinden können. Dieses Beispiel zeigt, wie man das Schreiben sämtlicher Dateien verhindern kann für ein vorhandenes Programm. In diesem Fall für eine Shell. Der jeweilige Sandkasten wirkt sich übrigens auch auf etwaige Kindprozesse aus.

Miami:~ macmark$ sudo -s
Password:
bash-3.2# whoami
root
bash-3.2# touch test
bash-3.2# rm test
bash-3.2# sandbox-exec -p "(version 1) (allow default) (deny network*) (deny file-write*) (debug deny)" /bin/bash
bash-3.2# whoami
root
bash-3.2# touch test
touch: test: Operation not permitted


---