ARCHIV 1999-2006

ARCHIV :: # 3428

Der mit dem OSX-Wurm tanzt

Interview mit Angelo Laub

Autor: flo - Datum: 03.01.2005

Der Vortrag von Angelo Laub letzte Woche auf dem 21C3 über Unsicherheiten in OS X, insbesondere über den ersten, echten Wurm für OS X (proof of concept), löste eine durchaus kontroverse Diskussion aus. Marcel Dietzmann, Student und System Administrator, war beim Vortrag dabei (es gibt sie, die Admins, die auf dem aktuellen Stand bleiben wollen ;) und hat uns damals schon auf den Vortrag und die Diskussion aufmerksam gemacht. Nun hat er uns freundlicherweise auch noch ein sehr ausführliches Interview mit Angelo Laub zur Verfügung gestellt, welches im Übrigen auch bei „shiftzwei zu lesen ist.

Seit der Einführung von 10.3 sind nicht weniger als 17 Security Updates veröffentlicht worden, wobei meist jeweils mehrere Lücken geschlossen wurden. Grund zur Panik besteht hingegen nicht, bis auf den Safari/HelpViewer-Bug ist bis heute keine einzige Lücke bekannt, die auch von außen ausgenutzt werden könnte, wie es sie auf der dunklen Seite zuhauf gibt. Dennoch sind Beiträge über potentielle Unsicherheiten des Systems nicht gleich nur Äußerungen von Wichtigtuern, denn die Sicherheit von OS X ist ja nicht gerade ein unbedeutendes Pro-Argument für alle Nutzer (und potentiellen Switcher). Deshalb und natürlich wegen der Vorführung eines möglichen X-Wurmes möchten wir Angelo Laub die Möglichkeit geben, sich ausführlich zur gesamten Thematik zu äußern. 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 weiterverbreiten konnten. Opener z.B. ist lediglich ein Shellskript, 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 Appleprodukte 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 herauszugeben...

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 davon, was 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 und dieses 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, unsere Fragen zu beantworten.

Gern geschehen.

----
Vielen Dank an Angelo Laub und Marcel Dietzmann. Wir hoffen, dass dieses Interview die Thematik noch einmal verständlich behandelt hat und möglichst einige offene Fragen klären konnte. Dass es abweichende Standpunkte zur Thematik gibt sollte natürlich auch klar sein. Informiert zu sein hat aber noch nie geschadet.

Kommentare

Ungeachtet der technischen Hintergründe,

Von: marvin | Datum: 03.01.2005 | #1
was wir als Kunden nicht vergessen dürfen: Wir haben diese Produkt (Mac Os X) teuer gekauft, dafür erwarte ich, dass es funktioniert und das es sicher ist. Punkt. Ich bin der Kunde, ich kaufe vielleicht morgen schon ein anderes Produkt. Wenn Apple das nicht begreift, sollte wir es ihnen beibringen -- schließlich wär's schade für die Mac-Zukunft.

(Sorry, bin gerade etwas angefressen; habe gerade auch den Hardwarebericht über Gilas G5 gelesen.)

FileVault?

Von: MetalSnake | Datum: 03.01.2005 | #2
Habe mal eine Frage zu FileVault. Bringt das wirklich was um sich vor "angriffen" oder was auch immer von außen zu schützen oder bringt das nur was um sich vor "Angreifern" zu schützen die direkten Zugriff auf den Rechner haben? Vorallem verstehe ich nicht wie das überhaupt schützt, wenn jmd. direkt an meinem Rechner sitzt und er hat zugriff kann er doch auch den Benutzerordner Lesen, man muss ja nicht wieder ein Passwort eingeben oder? Außerdem schützt doch der Bildschirmschoner mit Passwort auch vor direkten zugriffen.

ps: Der Link zum zweiten "Papier" funktioniert nicht.

Und noch gleich einen hinterher:

Von: marvin | Datum: 03.01.2005 | #3
"... und benutzt immer die aktuellste Version von Mac OS X".

Würde ich ja gerne, musste dann aber doch gestern wieder zu 10.3.5 zurück :-(

filevault...

Von: mullzk | Datum: 03.01.2005 | #4
... schützt die daten auch bei einem ansonsten erfolgreichen angriff von aussen. auch wenn sich ein angreifer root-rechte oder was auch immer besorgt hat, die daten in der filevault kann nur der lesen, der das passwort dazu (oder das hauptkenntwort) kennt....

@NetalSnake

Von: ctopfel | Datum: 03.01.2005 | #5
Durch FileVault ist der Benutzerordner verschlüsselt.
Nur mit dem richtigen Passwort können die Daten entschlüsselt werden. Der Schlüssel ist also nicht nur Zugang zu den Daten, sondern gleichzeitig auch ein "Fernglas", um die Daten betrachten zu können.

hat man das Passwort nicht, muss mit roher gewalt (brute force) jede möglichkeit durchprobiert werden, was lange zeit beansprucht.

Im Klartext: FileVault schützt deine Daten, wenn dir jemand den Laptop klaut. Der Dieb kann die Daten dann immerhin nicht lesen.

P.S. ich weiss nict ob es einen trick gibt, wie man das FileVault Passwort herausfinden kann, hoffe mal nein.

@MetalSnake (Link)

Von: flo (MacGuardians) | Datum: 04.01.2005 | #6
Die Seite scheint es nicht mehr zu geben oder sie ist momentan nicht erreichbar. Der Link zumindest stimmt eigentlich, wie eine kurze Ergoogelung ergibt...

vielleicht nochmal lesen

Von: Max | Datum: 04.01.2005 | #7
Vielleicht solltest Du den Beitrag nochmal lesen. Was dort steht bedeutet im Prinzip, dass OS X das sicherste Anwender OS auf dem Markt ist. Mit (erheblich) mehr Aufwand und Wissen kann man ein (erheblich) benutzerunfreundlicheres, aber sichereres System zusammenstellen. Na und? Was nützt Sicherheit, wenn man es nicht benutzen kann/will.

Feedback an Apple

Von: Jorge Pino Garcia | Datum: 04.01.2005 | #8
Ich habe nochmal versucht Apple durch den Bugreporter inkl. dem Upload des PDF-Files "OSXInsecurity" und eines Systemprofils darüber zu informieren.

Den Apple Bugreporter kann man hier aufrufen:
https://bugreport.apple.com/

FileVault...

Von: heinzkunz | Datum: 04.01.2005 | #9
... schützt _nicht_ gegen einen Angriff von aussen oder die Folgen davon. Wenn ein Angreifer auf deinem System root geworden ist, kann er auch dein Passwort herausfinden, spätestens wenn du dich das nächste mal einloggst.


Wie ctopfel schreibt, hat FileVault den Zweck vor Dieben zu schützen. Genauer gesagt schützt es vor physischem Zugriff: Wenn dein Computer an ist, du aber ausgelogged bist oder den Bildschirmschoner mit Passwortabfrage anhast, kann niemand deine Daten lesen indem er einfach den Computer im Target-Disk-Modus neustarter.


WICHTIG ist in diesem Zusammenhang aber der seit einiger Zeit bekannte Fehler, dass das Login-Passwort im KLARTEXT in den Auslagerungsdateien landen kann.

Die Chancen stehen ziemlich gut, dass euch folgendes Kommando in der Shell euer Passwort liefert:
sudo strings -8 /var/vm/swapfile? |grep -A 4 -i longname

Weitere Informationen hier: [Link]
Kommentare lesen.

Bevor dieser Fehler behoben ist (OS X 10.4), auf keinen Fall FileVault sensible Daten anvertrauen.

Naja, das FileVault-PW sollte nicht das Login-PW sein...

Von: Kabe | Datum: 04.01.2005 | #10
...worauf auch Apple selbst hinweist.

Insofern kann man FileVault schon sensible Daten anvertrauen, man muss nur die alte Regel beachten, PW nicht doppelt zu verwenden.

Kabe

NSA Security Configuration Guide für Panther

Von: Bodo | Datum: 04.01.2005 | #11
Benutzt einfach den folgenden Link zum NSA Security Configuration Guide für Panther, hat auch den Vorteil immer aktuelle Änderungen mitzubekommen:

[Link]

Hach putzig, jetzt taucht auch hier ein andere "Bodo" auf ...

Von: bodo | Datum: 04.01.2005 | #12
... allerdings großgeschrieben.

Unpatchte XP Systeme...

Von: Fustercluck | Datum: 04.01.2005 | #13
... überleben vielleicht 4 Minuten im Netz. 40 Minuten halte ich für absolut illusorisch.

Bei den "Security Nightmares 2005"...

Von: Marcel_75 | Datum: 04.01.2005 | #14
...ließ man sogar verlauten, dass man es schon in 26s geschafft hätte - das nur mal so am Rande... ;)

System Preferences

Von: macups | Datum: 09.01.2005 | #15
hallo zusammen,

Angelo erwähnt hier zum Thema: Voreinstellungen von Mac OS X...
"Das ist zwar in den System Preferences leicht zu ändern" (einfach "Für das Freigeben jeder geschützten Systemeinstellung ein Kennwort verlangen" aktivieren)

Frage wo kann ich das ganz "leicht" erledigen?

Danke

System Preferences

Von: macups | Datum: 09.01.2005 | #16
sorry:

ist wohl nur das schloss-symbol in der z.B. Benutzerverwaltung gemeint?!

lol

26 Sekunden

Von: real | Datum: 13.01.2005 | #17
> ...ließ man sogar verlauten, dass man es schon in 26s geschafft hätte - das nur mal so am Rande... ;)


Nu mal nicht übertreiben, es waren 28 Sekunden. :-)

Besser ohne filevault!?!

Von: JoEsIg | Datum: 12.03.2005 | #18
Hallo zusammen! Zum Thema filevault möchte ich an dieser Stelle – als Mac Neueinsteiger – etwas loswerden. Ich habe wohl den Fehler gemacht, das Programm einzusetzen ohne mich vorher mal im Internet oder bei alt eingesessenen Macusern danach zu erkundigen. Das Problem entstand als ich versucht habe überflüssige Daten von meinem Rechner zu löschen, weil angeblich auf meiner 160 GB HD nur noch 6,5 GB frei sein sollten. Das sichere Löschen der sich Papierkorb befindlichen Daten war nicht möglich, da filevault diese Daten scheinbar erst wieder entschlüsseln musste um sie dann endgültig löschen zu können. Bei größeren Datenmengen kann das dann schon mal ein paar Tage dauern (10 MB/min). Auch das deaktivieren von filevault wird in diesem Fall schwierig! Filevault verlangte nach ca. 46 GB freien Speicher auf der HD, nur wo soll man die herbekommen wenn man für das Löschen von 46 GB ca. 76 Std. benötigt? Den Rechner 3½ Tage laufen lassen? Das kann es ja wohl nicht sein, oder? Schlussendlich wurde das Problem anhand einer Anleitung von der Supportseite von apple.com gelöst. Das Ende vom Lied, meine Worddatein blieben lesbar, die Entourage Sicherung war hinüber und das System musste neu aufgesetzt werden; denn nach der Lösung die Apple vorgeschlagen hat, hätte ich jedem geschützten Ordner erneut eine Admin-Freigabe erteilen müssen, da war eine Neuinstallation einfach schneller.
Die Aussage eines Applemitarbeiters aus dem 2.Level dazu:“Lassen Sie die Finger von filevault, wenn überhaupt ist das eine bessere Testversion!“
Schönen Dank an Apple! Der Umstieg auf einen Mac ist gründlich daneben gegangen!!!

Broken link

Von: Peter Pan Vienna | Datum: 12.04.2005 | #19
Der Link zum zweiten Paper am Ende des Beitrages funktioniert nicht!

Schei* Spambots

Von: d4d4 | Datum: 25.05.2005 | #20
Schei* Spambots. Jetzt müssen die hier sogar noch bei Macguardinas rumspamen...

d4d4

teens

Von: indiana gambling boats invites | Datum: 28.11.2005 | #21
<h1>tutoring establishing familiarness allophonic motorcar?caution gratefulness overpower survivors sex sex [Link] http://www.realantiques.net/free-slot-machine.html not?seaweed </h1>

ICQ

Von: Jojo | Datum: 16.11.2005 | #22
Hallo,
Ich hab mein Passwort von einer e-mail adresse und bei dem Programm Icq vergessen wie kann ich das Passwort rausfinden ohne die hilfe von den seiten des programmes zu nutzen ?
M.F.G. Jojo