Interview mit Angelo Laub auf dem 21C3

In eigener Sache: Da die MacGuardians wie auch Shiftzwei ihre Blogs eingestellt haben, veröffentliche ich dieses interessante Interview nun zusätzlich in meinem eigenen Blog. Die beiden Original-Veröffentlichungen findet man bei Interesse noch im MacGuardians-Archiv bzw. mit Hilfe der Wayback-Machine bei Shiftzwei.

Diesen Artikel habe ich nun, entgegen den üblichen Blog-Gepflogenheiten, rückwirkend mit dem Datum 02. Januar 2005 online gestellt (an diesem Tag war das Interview fertig und final abgesegnet). 21C3 Flyer

Ende Dezember 2004 begab ich mich zum 21. Chaos Communication Congress in der Kongresshalle am Alex in Berlin.

Im Programm wurde für Tag 3 angekündigt: „218: Practical Mac OS X Insecurity – Security Concepts, Problems, and Exploits on Your Mac (Angelo Laub) • Some recent security problems with Mac OS X stem from the fact that Apple tries to combine the Unix security model with easy and convient usability and closed source. Showing examples from our own research we will take you on a pleasant journey to get root on almost any …“

http://events.ccc.de/congress/2004/fahrplan/event/218.de.html

Das wollte und konnte ich mir nicht entgehen lassen! Daraus entstanden ist das nun folgende Interview.

Hallo Angelo, stelle Dich doch bitte erst einmal kurz vor.

Ich studiere Physik und Mathematik in Bonn und habe die Bonner MacHackers mitgegründet. Begeisterter Macuser bin ich schon seit 1995.

Was sind Deiner Meinung nach die Stärken von Mac OS X?

Am wichtigsten: Das Cocoa Framework. Es gibt Cocoa-Programmen von Hause aus Möglichkeiten mit, die sonst erst in mühevoller Kleinarbeit in jedem Programm einzeln implementiert werden müssten. So ist es z.B. trivial, einem Cocoa-Programm das Rendezvous Protokoll, LaTeX-rivalisierende Qualität im Drucksatz oder Schlüsselbund- und Adressbuch-Anschluss beizubringen. Deshalb ist die Qualität von Cocoa-Programmen auf einem derart hohen Grundniveau angesiedelt. Des Weiteren sind die OpenGL beschleunigte grafische Oberfläche zu nennen, viel effizienteres Speichermanagement als unter Windows und die sichere, auf UNIX basierende Architektur.

Weniger glänzen jedoch Apples closed-source Sicherheitsaufsätze auf Darwin. Überall, wo Kompromisse zugunsten von Komfort eingegangen werden, habe ich eine Sicherheitslücke.

Nur ein Beispiel: Um das System für den Normalbenutzer so komfortabel wie möglich zu machen, ist es in der Standardeinstellung nicht bei allen vitalen Funktionen nötig, sein Passwort einzugeben.

Das heißt einige Voreinstellungen von Mac OS X sind also als unsicher einzustufen?

Ja. Während es z.B. vollkommen okay ist, dass man für das Ändern von Netzwerkeinstellungen oder ähnlichem kein Passwort braucht, gilt dies für das Anlegen von Admin-Usern nicht. Um beliebige Befehle als root auszuführen, muss ich lediglich einen neuen Admin-User anlegen und mich dann unter seinem Namen einloggen. Probiert es selbst aus: dies ist selbstverständlich möglich, ohne im Vorhinein das Admin-Passwort zu kennen. In der Standardeinstellung kann also jeder auf dem Mac beliebige Befehle als root ausführen. Das ist zwar in den System Preferences leicht zu ändern (einfach „Für das Freigeben jeder geschützten Systemeinstellung ein Kennwort verlangen“ aktivieren), aber es ist in der Voreinstellung nicht so eingestellt. Und die Voreinstellung ist ja schließlich das, was der Ottonormaluser auf seinem Mac eingestellt hat.

Ich hatte für meinen Vortrag auf dem Kongress ein Demo-AppleScript geschrieben, das in den Systemeinstellungen einen neuen Admin-User anlegt, und dann eine root-shell aufmacht. Und dies ohne jemals sein Passwort eingeben zu müssen! Ein klassischer root-Exploit in der standardmäßigen Mac OS X Installation.

Der Standarduser ist doch aber Administrator und darf deshalb sowieso alles.

Das stimmt so nicht. Es ist äußerst positiv an OS X anzumerken, dass der Standarduser eben KEIN Administrator ist, wie es unter Windows der Fall ist. Das heißt, er kann ohne weitere Authentifizierung keine systemweiten Änderungen durchführen. Will er dies tun, so geht das nur über sudo oder ein grafisches Äquivalent, was das bewusste Eingeben seines Passwortes notwendig macht. Gleiches gilt nun für Viren oder sonstige Malware. Sie ist, falls sie sich systemweit einnisten möchte, auf eine privilege escalation vulnerability angewiesen. Und wenn ich nun beliebige Befehle als root ausführen kann, ohne vorher mein Passwort eingegeben zu haben, dann ist das so eine privilege escalation vulnerability, die auch von Malware ausgenutzt werden kann.

Apple lässt sich stellenweise sehr viel Zeit für das fixen von Sicherheitslücken, das Problem mit den Zugriffsrechten für /Library/StartupItems ist z.B. seit März 2004 bekannt, die Auslagerung von Passwörtern (im Klartext!) in Swap-Files immerhin auch schon seit Juni 2004. Wie gefährlich sind diese Lücken und warum braucht Apple so lange, diese Probleme anzugehen?

Nun gut, diese Art von Sicherheitslücken sind bei weitem nicht so kritisch wie jene, die man von MS Windows gewohnt ist, da sie nicht remote auszunutzen sind. Trotzdem meine ich, dass man sie fixen sollte.

Das Problem bei Apple ist auch gar nicht, dass zu wenige oder zu selten Sicherheitsupdates veröffentlicht werden. Das Problem ist, dass Apple manche der mitgeteilten bzw. bekannten Sicherheitslücken anscheinend nicht ernst nimmt und diese einfach nicht fixt. Seit Oktober, als ich Apple die Lücke in den System Preferences mitteilte, gab es bereits zwei Updates für Mac OS X 10.3 und zwei zusätzliche Sicherheitsupdates. Es ist aber immer noch nicht gefixt und bis zum Tag meines Vortrages gab es trotz wiederholter Anfrage keinen Kommentar von Apple zu hören. Dies war der Grund, warum ich mich entschlossen hatte, mit dieser Angelegenheit an die Öffentlichkeit zu gehen.

In alternativen Unix-Derivaten wird also mehr Wert auf das Thema Sicherheit gelegt?

Was die Lücke in den System Preferences angeht, so würde sich ein solches Problem in anderen Unixes gar nicht erst stellen, da sie größtenteils nicht für den Endbenutzer vorgesehen sind. Was Apple ja macht ist, Hacks in das System einzubauen, damit User administrative Aufgaben ausführen können, ohne das Passwort eingeben zu müssen. Das heißt die meisten Sicherheitslücken beziehen sich gar nicht auf das zugrunde liegende Unix (Darwin), sondern nur auf die closed-source-Erweiterungen von Apple.

Es gibt leider immer wieder Benutzer die glauben, dass Closed Source relativ „sicher“ sei, da man ja nicht wissen könne, was genau „in der Blackbox“ passiert. Bitte erläutere doch einmal kurz, wie das ReEngineering von Closed Source funktioniert und warum es ein Trugschluss ist zu glauben, solcher Programmcode sei nicht hackbar.

Der Umstand, dass ich den Quellcode eines Programmes nicht kenne, macht es nicht zwangsläufig sicherer. Ganz im Gegenteil besteht die Gefahr beim Schreiben einer closed-source-Anwendung, unsicheres Design zu verwenden, weil der Quellcode ja eh nicht veröffentlicht wird. Am Beispiel Objective-C ist es sogar trivial herauszufinden, wie das Programm aufgebaut ist und welche Funktionen wann und wofür aufgerufen werden. Die kompletten Header-files mit den gesamten Klassen- und Methodendefinitionen stehen im Klartext im Binary. Um die Header aus dem Binary auszulesen gibt es eigens das Tool class-dump. Sind die aufgerufenen Methoden oder Funktionen erst einmal bekannt, ist es ein Leichtes, sie mit Hilfe von Mach Injection zu überschreiben. So kann ich jeden einzelnen Teil eines closed-source-Programms austauschen und einer genauen Wirkungsanalyse unterziehen.

Das Programm „RendezPoo“ führte auf dem Kongress einen erfolgreichen „Denial of Service“-Angriff auf Apples Personal Filesharing vor. Könnte man dieses Problem mit DiskQuotas lösen oder wäre eine feinere Justiermöglichkeit für einzelne „Gast-Benutzer ohne Administrations-Rechte“ sinnvoller?

Das Problem an Apple Filesharing ist ja, dass der Gast-User einfach so die Festplatte über das Netzwerk voll schreiben kann, was den Rechner früher oder später abstürzen lässt.

Als Lösung hatte ich in meinem Vortrag vorgeschlagen, dass der Gast-User in der Voreinstellung deaktiviert sein soll und man ihn in den System Preferences an- und ausschalten kann. Alternativ oder zusätzlich wäre auch eine DiskQuota möglich, aber soweit ich weiß, kann man bisher nur Quotas für einen gesamten User setzen. Die Dateien des Gast-Users landen jedoch bei den Dateien des normalen Users, so dass man den Standardbenutzer beschränken müsste.

Ich kann mir nicht vorstellen, wie Apple dem Ottonormaluser klarmachen will, dass er eine Quota auf seinen Homefolder setzen muss. Vorschläge, man solle den Swap auf eine eigene Partition auslagern halte ich in Mac OS X für ebenso wenig praktikabel, da man für manche Dinge eine ziemlich große Swap Partition braucht. Insbesondere auf den neuen 64 Bit Prozessoren kann ja ein nahezu beliebig großer Speicheradressraum verwaltet werden. Wie groß sollte man die Standardswappartition machen? 400 MB, 1.2 GB, 4 GB oder 12 GB auf 64 Bit Systemen? Sollte man den User auswählen lassen? Wie ändere ich das im Nachhinein? Ziemlich viele Fragen…

Kommen wir zu einem der mit Sicherheit heißesten Themen: „Mach Injection“. Was hat es damit auf sich?

Also erstmal vorweg: Der Umstand, dass Mach Injection möglich ist, war eine Designentscheidung bei der Entwicklung von Mac OS X. Da man sich für eine Mach-Microkernel-Architektur entschieden hatte, bekam man Mach Injection automatisch mitgeliefert.

Ich werde erstmal erklären, was klassisch auf allen Unix- und Windowssystemen möglich ist und dann, wodurch sich Mach Injection davon unterscheidet.

1) Klassisch: Man kann den dynamischen Linker dazu zwingen, vor dem Programmstart bestimmte shared libraries vorzuladen und auf diese Weise Code in vorhandene Programme injizieren. Diese Methode ist unter dem Namen der zuständigen Umgebungsvariablen, LD_PRELOAD unter Linux, DYLD_INSERT_LIBRARIES unter Mac OS X, bekannt. Auch hier ist es möglich, bestimmte C-Funktionen zu überschreiben. Das ist wirklich nichts Neues und auch schon seit Ewigkeiten bekannt.

2) Mach Injection: Mit Mach Injection kann ich alles machen, was klassisch geht, nur kann ich dies auch zur Laufzeit tun. Das heißt, ich kann auf den Speicherbereich eines beliebigen anderen Programms zugreifen und zur Laufzeit beliebigen Code hineinschreiben und sogar aus der Ferne einen neuen Thread erzeugen, der den hinzugefügten Code ausführt. Das muss man sich erst einmal auf der Zunge zergehen lassen! Dabei kann man gar nicht oft genug betonen, dass dies alles zur Laufzeit möglich ist, also wenn das Programm schon längst läuft und seinen Dienst verrichtet. Das Programm selbst (und erst recht der User) merkt davon nichts.

Des Weiteren ist noch zu bemerken, dass all dies von außen zwanghaft geschieht und das Programm keine Chance hat, sich dagegen zu wehren.

Welche konkreten Angriffspunkte auf ein System wären mit dieser Technik denkbar?

Im Wissen, dass Mach Injection und DYLD_INSERT_LIBRARIES jederzeit möglich ist, muss einem klar werden, dass es keine vertrauenswürdigen Programme gibt, auch nicht, wenn man eine Prüfsumme des Binary überprüft. Überall, wo ich eine Liste von vertrauenswürdigen Programmen habe und sie über eine Binary-Prüfsumme absichere, habe ich also theoretisch eine Sicherheitslücke. In Mac OS X ist dies z.B. bei dem Schlüsselbund (Keychain) der Fall.

Könnte ein eingeschränkter Benutzer-Account ein Programm, das mit Root-Rechten läuft, in irgendeiner Weise beeinflussen, um selbst Root-Rechte zu erlangen?

Nein, das ist Steve sei Dank nicht möglich. Es ist als normaler User nicht möglich, Code in den Prozess eines anderen Users zu injizieren (auch nicht in setuid root Programme).

Kommen wir auf Deinen „Proof-of-Concept“-Wurm zu sprechen. Er basiert auf der nach wie vor gegebenen Möglichkeit, ein ausführbares Programm z.B. als PDF oder MP3 tarnen zu können. Eigentlich nahm ich an, dies wäre von Apple schon vor einigen Monaten gefixt worden? Offensichtlich ist dem nicht so? Könntest Du uns etwas mehr zu Deinem Wurm erzählen? Was unterscheidet Deinen Wurm z.B. von Opener? Und kursiert dessen Quellcode schon im Netz? Oder haben ihn „Fremde“ ohne Deinen Quellcode“ nachgebaut?

Ich nahm anfänglich auch an, dass diese Lücke schon gefixt wäre. Als ich jedoch das Gegenteil feststellen musste, war ich erstmal ziemlich enttäuscht von Apple. Deshalb entschloss ich mich, mit der ganzen Sache an die Öffentlichkeit zu gehen und wurde von Freunden aus dem CCC dazu ermutigt, auf dem 21C3 einen Vortrag zu halten.

Um den Handlungsdruck bei Apple zu erhöhen, entschloss ich mich, sozusagen eine verschärfte Version des bereits im April diskutierten MP3.concept-Trojaners zu kreieren.

Im Gegensatz zu dem alten Trojaner besitzt mein Wurm eine eigene SMTP-Engine, was ihm nicht nur ermöglicht, unerkannt über z.B. E-Mail auf das System zu gelangen und lokal „bösen“ Code auszuführen, sondern auch andere Systeme zu befallen. Er verschickt sich ab Aktivierung automatisch und unbemerkt an alle E-Mail-Adressen im systemeigenen Adressbuch.

Bekommt man ihn per E-Mail, so sieht er aus wie ein ganz normales PDF-Dokument. Speichert man es ab und doppelklickt darauf, so öffnet sich auch tatsächlich ein PDF-Dokument mit dem Standard-PDF-Viewer, so dass der Benutzer keinen Verdacht schöpft.

Ich glaube, dass dieser Wurm eine realistische Chance hätte sich zu verbreiten, würde er freigesetzt.

Der „Proof-of-Concept“ ist hiermit vollbracht, jetzt ist Apple an der Reihe, endlich die Lücke zu schließen.

Ich nenne ihn deshalb den „ersten Wurm für Mac OS X“, weil alle Versuche davor höchstens Trojaner waren, sich jedoch nicht selber weiter verbreiten konnten. Opener z.B. ist lediglich ein Shell-Skript, ohne die Möglichkeit, sich zu verstecken oder automatisch zu verbreiten. Hinzu kommt, dass Opener root-Rechte benötigt, um zu funktionieren.

Den Quellcode möchte ich vorerst nicht veröffentlichen. Es wäre dann sicher davon auszugehen, dass Skriptkiddies ihn „in die freie Wildbahn“ aussetzen würden, was aufgrund der Mächtigkeit des Wurms vermutlich nicht sehr lustig wäre.

Obwohl er in seiner jetzigen Form keine Schadroutine sondern lediglich eine Verbreitungsroutine enthält, wäre diese erstens sehr leicht einzufügen und zweitens würde er sich auch ohne diese vermutlich recht schnell verbreiten.

Erscheint denn das „böse“ PDF auch mit einem Standard-PDF-Icon? Falls ja, wie kann man erkennen, dass es sich um eine infizierte Datei handelt?

Das „böse“ PDF-Dokument ist für den User auf den ersten Blick nicht von einem gewöhnlichen PDF zu unterscheiden. Es trägt die korrekte Dateiendung und das korrekte Symbol für ein PDF-Dokument. Erkennen, dass es sich in Wirklichkeit um ein Programm handelt, kann man nur, wenn man sich mit Command-I die Dateiinfos bzw. mit Control-Klick den Paketinhalt anzeigen lässt. Bekommt man es per E-Mail über Mail.app zugeschickt, so erscheint es in der E-Mail als völlig normales PDF-Dokument mit der richtigen Dateiendung (siehe Screenshot). Klickt man darauf, warnt Mail.app einen noch nicht einmal, dass es sich um eine Application handelt, sondern bietet einem die Möglichkeit es abzuspeichern. Klickt man anschließend darauf, so öffnet sich auch tatsächlich ein PDF-Dokument mit dem Standard-PDF-Viewer, so dass der User keinen Verdacht schöpft. Im Hintergrund läuft das Programm aber weiter und verschickt sich mit eigener SMTP-Engine an alle E-Mail-Adressen im systemeigenen Adressbuch. Auch denkbar, aber noch nicht implementiert, wäre die Möglichkeit, dass der Wurm beliebige andere Dokumente (nicht nur PDFs) infiziert.

Ein weiteres Thema waren 2004 erste rootkits für Mac OS X (u.a. WeaponX). Wie gefährlich sind diese für Mac OS X und müssen wir eventuell mit ersten großflächigen Angriffen im kommenden Jahr rechnen?

Rootkits im herkömmlichen Sinne sind selbst nicht in der Lage, sich zu verbreiten. Sie dienen dazu, es sich auf dem anzugreifenden System bequem zu machen und Spuren zu verwischen, sobald man sowieso schon den kompletten Zugriff hat. Tatsächliche Gefahr geht deshalb nicht von rootkits aus, sondern von Lücken, welche die Verbreitung von Malware ermöglichen.

Glücklicherweise ist es bisher nicht möglich, Mac OS X „direkt von außen“ anzugreifen. Ist dies nur bei einem mit allen Sicherheitsupdates versehenen Mac OS X 10.3.7 der Fall oder gilt dies auch für ein ungepatchtes Mac OS X 10.0.0?

Ein völlig ungepatchtes Mac OS 10.0 würde ich auf keinen Fall noch einsetzen. Schon allein was die Performance betrifft gibt es keine Gründe, da 10.3 trotz höherer Versionsnummer deutlich schneller und Ressourcenschonender arbeitet. Es gab damals z.B. noch Buffer Overflow Lücken in Apple Filesharing und der DHCP-Client war verwundbar. Praktischerweise ist Apple Filesharing in der Standardinstallation nicht aktiviert und letztere Lücke ließ sich nicht über das Internet ausnutzen, was einem derartig alten System wahrscheinlich immer noch eine ziemlich lange Überlebenszeit bescheren dürfte. Zum Vergleich: Ein ungepatchtes Windows XP überlebt maximal 40 Minuten im Netz. Mac OS X hat keine offenen Dienste und keine bekannten remote holes.

Welche neuen Sicherheitskonzepte bringt Mac OS X 10.4 Tiger mit sich? Eröffnen sich z.B. durch das Suchsystem „SpotLight“ oder die stärkere Integration des Safari WebKits in das System neue Angriffsmöglichkeiten ähnlich der Kombination „Internet Explorer & Windows“?

Während in 10.3 Panther erstmals die Möglichkeit gegeben wurde, seine persönlichen Daten mit FileVault zu verschlüsseln, bekommen wir mit 10.4 Tiger nun auch die Option, den Swap zu verschlüsseln, was zumindest schon mal Schluss mit Klartextpasswörtern im Swap machen dürfte.

Ansonsten hat sich, soweit ich das sehen kann (ich hätte gern Tiger zum Testen, aber eine Apple Select Mitgliedschaft kann ich mir nicht leisten) an der Sicherheitsfront nicht viel geändert. Die System Preferences Lücke ist in Tiger z.B. auch noch drin.

Neue Features wie SpotLight würden es Spyware sicherlich leichter machen, den Benutzer auszuspähen, jedoch ist dies prinzipiell nichts, was die Spyware nicht auch so schon, wenn auch komplizierter, gekonnt hätte.

Sorgen machen mir ein wenig die starke Integration von Mail und Safari in Mac OS X, ähnlich dem Gespann Internet Explorer, Outlook, Windows. Ein Angreifer kann so mit einer Standardkombination von Software rechnen, auf die er seinen Angriff dann genau zurechtfeilen kann. Zuträglicher für die Sicherheit wäre natürlich ein Mischwald aus verschiedenen Browsern und Mailprogrammen, was bei der hohen Benutzerfreundlichkeit und Qualität der vorinstallierten Apple-Produkte allerdings schwer sein wird.

Eventuell möchtest Du auch noch einmal genauer auf den Safari/Help Viewer Bug eingehen, um Deine bisherigen Argumente zu untermauern?

Der Safari/Help Viewer Bug war der erste, bei dem man von außen beliebigen Code ohne jegliches Zutun des Benutzers ausführen konnte. Dieser Bug ist ja nun schon länger gefixt, aber es ist natürlich durchaus möglich, dass irgendwo in den Tiefen zwischen Safari, Mail.app und Mac OS X noch ähnliche Sicherheitslücken lauern. Von Windows kennen wir das ja so, dass ein Bug selten allein kommt. Bei Mac OS X muss das allerdings nicht zwangsläufig so sein.

Waren die letzten Monate/Jahre also eventuell nur die sprichwörtliche „Ruhe vor dem Sturm“?

Anhand der Fülle von momentan bekannten und ungefixten Lücken liegt diese Befürchtung nahe. Insbesondere wenn der Marktanteil von Mac OS X weiter steigt, kann damit gerechnet werden, dass die Mac-Plattform auch für Spammer interessant wird, die ja ständig auf der Suche nach Zombierechnern für das Spam-Relaying sind. Es könnte meiner Einschätzung nach tatsächlich etwas auf uns zukommen, wenn Apple das Thema Sicherheit nicht bald noch ernster nimmt.

Dir geht es ja vor allem um die Tatsache, dass Apple sich in mancher Beziehung mehr Zeit als nötig lässt, um Dinge zu fixen. Der Quellcode Deines Wurms sollte ja ursprünglich veröffentlicht werden, erste wirklich gefährliche Exploits würden dann sicher nicht lange auf sich warten lassen – der Wettlauf zwischen Apple (mit dem Fix der Schwachstelle) und den Hackern wurde also sozusagen spätestens seit dem 21C3 offiziell eingeläutet?

Das könnte man tatsächlich so sehen, schließlich ist ein bisschen Wettlauf der Produktivität durchaus zuträglich … 😉

Allerdings habe ich nicht vor, den Quellcode zu veröffentlichen, bevor Apple genug Gelegenheit gehabt hat, die Lücke zu fixen.

Könnten Änderungen in Mac OS X, wie z.B. ein echtes Unix Filesystem oder ein anderer MicroKernel statt Mach, das System sicherer machen?

HFS+ ist in seiner neuesten Version eines der modernsten und coolsten Filesystems. Es unterstützt Journaling, entgegen der landläufigen Meinung auch case-sensitivity und bietet automatische Defragmentierung. Dinge wie ResourceForks und Type/Creator sind sicherlich nervig und könnten eventuell anders gehandhabt werden, sind aber auch nicht unbedingt sicherheitsrelevant. Wie immer, wenn man solche grundlegenden Sachen ändert, verliert man die Kompatibilität zu älterer Software. Apple müsste also selbst schauen, ob man da vielleicht irgendetwas sanitizen kann, ohne die Kompatibilität allzu arg zu brechen.

Ob Mach Injection so einfach im Kernel deaktiviert werden kann, ohne viele andere Dinge kaputt zu machen, weiß ich nicht. Fest steht ja, dass Mach Injection auch nützliche Anwendungen hat, wie z.B. Desktop Manager. Besser wäre es glaube ich, das Sicherheitssystem in Mac OS X einfach so zu designen, dass es nicht anfällig für Attacken über Mach Injection ist.

Bei den MacHackers auf dem Kongress hattest Du ja dazu aufgerufen, man solle sich mit dem Thema „Mach Injection“ näher beschäftigen – gab es denn schon erste nennenswerte Resultate diesbezüglich?

Ich sag nur soviel: Keychain. Mehr möchte ich darüber nicht sagen, bevor Apple nicht informiert worden ist und Zeit hatte, einen Fix heraus zu geben …

Inwieweit gibt es erste „internationale“ Reaktionen? Hat Dein „Proof-of-Concept“-Wurm und das Thema „Mach Injection“ auch schon außerhalb Europas die Runde gemacht (mal abgesehen von diesem Artikel [Dynamically Overriding Mac OS X von Jonathan ‘Wolf’ Rentzsch], der ja schon seit Sommer 2003 bekannt ist)?

Die Reaktionen, die ich bekommen habe, stammen größtenteils aus Deutschland, was mich ein wenig wundert, da die Folien und das Paper in den Congress Proceedings ja auf englisch verfasst sind. Am Apache-Log kann ich jedoch sehen, dass z.B. mehrere Leute bei Apple sich meine Folien heruntergeladen haben, was bedeutet, dass sie sich für die Sache interessieren. Und Apples Interesse wecken ist ja schließlich eine der Hauptsachen, die ich erreichen wollte. Wie ich es gesehen habe, sind die Möglichkeiten der Mach Injection selbst bei Cocoa-Entwicklern größtenteils unbekannt. Ich nehme deshalb an, dass sich noch nicht viele Leute damit beschäftigt haben und deshalb auch noch keine Folgen für die Sicherheit bekannt sind.

Würdest Du den Benutzern da draußen abschließend noch etwas mit auf den Weg geben was die Sicherheit ihrer täglichen Arbeitsumgebung betrifft?

Ich denke, das ist inzwischen zum Teil schon angeklungen. Zusammenfassen könnte man das wie folgt:

Ein System ist nur so sicher wie der User, der es bedient. Also nicht blind auf alles draufklicken, was ihr zugeschickt bekommt. Verlasst euch nicht auf die Standardeinstellung, denn sie ist unsicher. Benutzt FileVault, sperrt immer euren Screen, wenn ihr kurz Kaffee holt. Lest dieses [Practical Mac OS X Insecurity – Security Concepts, Problems, and Exploits on Your Mac by Angelo Laub] und dieses [Apple Mac OS X 10.3.x Panther Security Configuration Guide] Paper und beherzigt die dort genannten Sicherheitsratschläge. Benutzt das Software Update und benutzt immer die aktuellste Version von Mac OS X. Steve weiß meistens was für uns gut ist.

Angelo, vielen Dank dass Du Dir die Zeit genommen hast, meine Fragen zu beantworten.

Gern geschehen.

Aktualisierung 17. Juni 2015: Angelo hatte es vor mittlerweile über 10 Jahren auf dem Kongress bereits angedeutet, nun bewahrheitet es sich – das Schlüsselbund von OS X ist mit äußerster Vorsicht zu genießen!

Keychains raided, sandboxes busted, passwords p0wned, but Apple silent for six months:

http://www.theregister.co.uk/2015/06/17/apple_hosed_boffins_drop_0day_mac_ios_research_blitzkrieg/

Paper (PDF) [Unauthorized Cross-App Resource Access on Mac OS X and iOS]