0. Technische Aspekte von Mac OS X und verwandte Themen Inhaltsverzeichnis

0.11 OS X - Security orthodox

Eine Beurteilung von heises "Security paradox"-Artikeln in c't, Mac&i und auf heise.de.

Stichwort-Liste

0.11.1 Einleitung

Heise-Autor Tobias Engler hat sich Anfang 2011 einige Artikel bezüglich Sicherheit von OS X in der c't, der Mac&i und online geleistet unter Titeln wie "Security paradox: Mac OS X hat Mängel – doch keiner nutzt sie aus". Ich zeige hier, daß die Situation keineswegs paradox und die Sicherheit dem orthodoxen Ansatz von Unix zu verdanken ist.

Der grundlegende Fehler, den Tobias begeht, ist, die wirklich wichtigen Sicherheitsaspekte außer acht zu lassen und sich nur mit ein paar unwichtigen Randerscheinungen zu beschäftigen. OS X ist per Architektur sauber aufgestellt während Windows unrettbar broken by design ist, was Sicherheit angeht.

Seine Artikel über die von ihm überbewerteten Sicherheits-Beilagen enthalten darüber hinaus auch noch diverse sachliche Fehler, die entweder auf schlampiger Recherche oder purer Unkenntnis des Systems beruhen - oder beidem. Erschreckenderweise gilt das zum Teil auch für die interviewten Hacker.

Tobias schließt in bester Switcher-Manier von dem anders funktionierendem Windows auf OS X. Er rätselt, warum das gesund entworfene OS X ohne die Krücken überleben kann, auf die ein architekturmäßig verbocktes Windows angewiesen ist. Er tut das in einer Weise, wie ein Longhorn sich darüber wundern würde, daß Leoparden und Löwen weder Gras noch Klee fressen müssen, um zu überleben.

In den folgenden Abschnitten schreibe ich über reale und vorgetäuschte Sicherheit. Anschließend durchleuchte ich vor diesem Hintergrund die verschiedenen Heise-Artikel. Bei dort wiederholt gemachten Fehlern kann ich dann auf diese Absätze verweisen ohne alles mehrfach schreiben zu müssen.

Wenn es nur um mich ginge, hätte ich diese Artikel komplett ignoriert, weil sie ein grundlegend falsches Sicherheitsverständnis an den Tag legen und schlecht recherchiert sind. Ich habe aber bemerkt, daß viele Leute von diesen Artikeln in die Irre geführt werden und grundlos in Sorge geraten, weil sie diese in vermeintlichen Fachzeitschriften gelesen haben. Daher mache ich mir die Mühe und beurteile diese Artikel mal fachlich.

0.11.2 Reale Sicherheit

Unix hat mindestens drei interne Sicherheitsgrenzen, die vor böswilligen Benutzern oder fehlerhaften Programmen schützen: Erstens schützt Unix die Prozesse gegeneinander. Zweitens kann der typische Benutzer die Dateien anderen Benutzer weder ändern noch lesen. Drittens läuft möglichst wenig Code mit privilegierten Rechten.

Das perfekte Anti-Unix beseitigt oder umgeht den Speicherschutz, so daß ein Amok-Prozeß andere Programme beeinträchtigen kann. Und diese Beeinträchtigung sogar gewollt ist. Seine typischen Benutzer können die Dateien anderer Benutzer und Systemdateien verändern. Und es läßt große Teile von Code, beispielsweise das GUI unter privilegierten Rechten laufen, so daß ein Angriff darauf zur Bedrohung des gesamten Systems wird.

Weitere grundlegende Sicherheitsaspekte sind Dinge wie sichere Suchpfade für ausführbare Dateien oder Netzwerk-Ports nur für Netzwerk und nicht für lokale Aufgaben zu verwenden. Solche grundsätzlichen Architekturfehler ergänzen sich auch prächtig.

Solche grundlegenden Architekturfehler, besser gesagt das Nichtbeachten von Sicherheitsaspekten beim Entwerfen des Systems, verdammen ein System zur Unsicherheit. Aufgrund dieser grundsätzlichen hausgemachten Sicherheitsprobleme versucht Microsoft zu retten, was zu retten ist. Das Grundproblem hierbei: Jeder Fehler in jedem Userland-Programm auf Windows kann aufgrund dieser Architekturfehler das System kompromittieren. Das Fatale daran ist, daß es sich nicht nur um einen einzelnen Riesenfehler handelt, sondern um mehrere, die jeder für sich schon ausreichten. Und Microsoft hat keine Chance das zu beheben ohne massive Kompatibilitätsprobleme einzugehen.

Was bleibt Microsoft übrig? Erstens ordentlich Geld für Marketing-Maßnahmen ausgeben, die erzählen, wie wichtig man doch Sicherheit nimmt. Und zweitens mehr oder weniger hilfreiche Techniken implementieren, die das Ausnutzen von Fehlern auf dieser schwachen Architektur möglichst verhindern sollen. Denn wenn ein Fehler ausgenutzt wird, ist gleich das System fällig. Im Gegensatz zu jedem Unix, bei dem ein ausgenutzter Fehler in einem Userland-Programm aufgrund der gescheiten Architektur nicht gleich das System in Gefahr bringt.

0.11.3 Vorgetäuschte Sicherheit

Microsoft Windows verwendet verschiedene Techniken, die als Sicherheitsmaßnahmen verkauft werden. Das verbessert Microsofts Image in der Presse, denn man muß etwas genauer hinsehen, um zu erkennen, daß die Maßnahmen keine reale Sicherheit bieten können.

0.11.3.1 UAC

Eine dieser Techniken habe ich hier schon ausführlich untersucht: UAC, das Sicherheits-Plazebo. Die gefühlte, aber nicht vorhandene Sicherheit der UAC. Die Kurzfassung ist: Die Trennung funktioniert nicht und die typischen Benutzer und Schadprogramme haben weiterhin Systemrechte.

0.11.3.2 Firewalls

Eine weitere prominente Maßnahme unter Microsoft Windows sind Firewalls. Die sind bei Microsoft Windows auch tatsächlich nötig, bei OS X jedoch nur bedingt sinnvoll. Zusammengefaßt: Microsoft Windows und seine Programme haben eine lange Tradition, Netzwerk-Ports zu verwenden, auch wenn das für die Umsetzung der eigentlichen Funktionalität überhaupt nicht notwendig wäre. Um diese Situation in den Griff zu bekommen, setzen sie eine Firewall davor. Unix-Systeme wie OS X und ihre Programme machen nur die allernötigsten Ports auf und die braucht man dann auch wirklich. Daher bringen Firewalls hier eher Schaden als Nutzen.

Firewalls auf Microsoft Windows müssen also ein Problem beheben, das es bei gescheiter Architektur und unter Programmen von Unix-Entwicklern in diesem Ausmaß überhaupt nie geben würde.

0.11.3.3 Mitigations: DEP und ASLR

Abmilderungen – die coolen Kids nennen es "Mitigations" – sind Techniken, die einzig und allein dazu da sind, das Ausnutzen von Bugs – die Hacker nennen es "das Exploiten" – schwieriger zu machen.

Microsoft hat Haus und Hof auf zwei prominente Mitigations, DEP und ASLR, als Sicherheits-Mechanismen verwettet. Dabei war die Nutzlosigkeit von ASLR besonders auf 32-Bit-Systemen, die zur Zeit noch den Löwenanteil der installierten Windows-Systeme ausmachen, schon lange bekannt.

Es gibt diverse Methoden, um erfolgreiche Exploits in der Gegenwart von DEP und ASLR zu schreiben. So hat selbst ein ehemaliger Microsoft-Mitarbeiter, Berend-Jan Wever (SkyLined), ein Beispiel veröffentlicht, das "dabei helfen soll, zu erklären, warum man in DEP und ASLR nicht allzu viel Vertrauen setzen sollte, speziell auf x86-Plattformen".

Ein anderer Heise-Autor, Jürgen Schmidt, berücksichtigt im Gegensatz zu Tobias Engler, daß DEP und ASLR relativ unnütz sind. Allerdings nennt er nur einen Weg, nämliche JIT-Spraying, der diese beiden Techniken alt aussehen läßt.

Tobias Engler hingegen verweist nur dann auf die Nutzlosigkeit dieser beiden Mechanismen, wenn es ihm um OS X geht. Dabei fällt ihm nicht auf, daß sowohl der von ihm referenzierte Artikel seines Kollegen als auch das von ihm selbst verlinkte Whitepaper ausschließlich von Windows sprechen. Auf der anderen Seite lobt Tobias jedoch diese weitgehend unnützen Techniken über den grünen Klee, wenn es um ihren Einsatz in Windows geht. Dabei sind DEP und ASLR auf allen Systemen prinzipbedingt nicht besonders wirksam.

Alexander Sotirov hat in seiner Präsentation und seinen Code-Beispielen und Forschungs-Veröffentlichungen verschiedene praktische Wege demonstriert, mit denen DEP und ASLR auf Microsoft Windows (und prinzipiell auch auf anderen Systemen) erledigt sind.

Microsoft bezieht sich höchstselbst auf diese Ergebnisse und konstatiert, daß DEP und ASLR umgangen werden können. Sie sehen den hauptsächlichen Nutzen dieser Techniken zur Zeit nur noch darin, daß alte Exploits nicht damit funktionieren, weil diese die neue Situation halt nicht berücksichtigen, sozusagen inkompatibel sind. Allerdings kommen sämtliche neuen Angriffe problemlos damit klar. Mitte 2011 ist die Lage sogar so, daß Hacker DEP und ASLR im wahrsten Sinne des Wortes als ziemlich wertlos betrachten.

Unter OS X bringen diese beiden Techniken keine besondere zusätzliche Sicherheit, weil es keine alten Angriffe gibt, die dadurch inkompatibel würden, denn die Fehler, die ausgenutzt werden konnten, sind eh behoben und neue Angriffe würden sich auch hier nicht durch diese Techniken aufhalten lassen.

Auch andere "Abmilderungs-Techniken" (die coolen Kids sagen "Mitigations") stellen sich regelmäßig als wirkungslos heraus: Der Schutz vor dem Ausnutzen von Heap-Überläufen wird beispielsweise deaktiviert, sobald man die Funktion, die der Fragmentierung des Heaps entgegenwirken soll, einschaltet. Diese Optimierung verbessert also auch gleich die Möglichkeiten des Angreifers.

0.11.4 Rezensionen

Oben habe ich vorgestellt, wodurch reale Sicherheit gewährleistet wird und welche prominenten Sicherheits-Techniken nur im Werbeprospekt (und in bestimmten Heise-Artikeln) ihre Wirkung entfalten. Als nächstes werde ich die verschiedenen Publikationen von Tobias Engler im Licht dieser Erkenntnis untersuchen.

0.11.4.1 heise.de: "Schwere der Lücken ist besorgniserregend"

Der Artikel "Schwere der Lücken ist besorgniserregend" ist ein Interview mit Felix von Leitner.

Felix "Fefe" von Leitner

Fefe – Felix von LeitnerFefe ist einmal in einem interessanten anderen ausführlichen Video-Interview von dctp.tv (daher auch das Photo) einmal vorgestellt worden. Er nimmt sich die Freiheit, auch manchmal Sachen ins Netz zu stellen, die mit Absicht nicht stimmen, "um die Medienkompetenz der Leser zu steigern". Ansonsten geht er in der Regel nicht thematisch in die Tiefe, sondern produziert Schlagzeilen, die ganz oft keinerlei sachliche Begründung haben. Manche reden von der "Bild-Zeitung für Nerds", wenn sie von seinem Blog sprechen.

Felix "Fefe" von Leitner disqualifiziert sich selbst absichtlich als verläßliche Informationsquelle, weil er dafür die Prioritäten falsch setzt: Spaß ist ihm wichtiger als Fakten und journalistische Sorgfalt.

Der Fokus liegt auf Spaß und thematischer Breite, nicht so sehr auf Fakten, journalistischer Sorgfalt oder ähnlichen Unterhaltungsbremsen. Nachlesen und herausfinden, was wirklich passiert ist, sollt ihr schließlich selbst :-)

Beispiel: Er lästert darüber, daß Apple laut diesem Bericht Samba durch eine eigene Implementierung ersetzen wird:

… das wird sicher episch schlecht. … Samba hat ja schon eine eher ... gemischte Geschichte in Sachen Sicherheitslücken, aber Apple? Apple wird hier sicher neue Standards setzen. … Meine Prognose: wir werden da Bugs sehen, die seit Jahren als ausgestorben galten. Und dabei waren über das Netz ausnutzbare Lücken gerade dabei, so selten zu werden, dass man kaum noch richtig Spaß beim Congress und beim Camp haben konnte! *händereib*"

[Update 2012]Inzwischen hat sich herausgestellt, daß Apple ganz gut damit gefahren ist, das Original-Samba zu ersetzen.[/Update 2012]

Er trollt einfach nur herum und vernachlässigt drei wichtige Punkte:

Ist jemand, der bei Sicherheits-Themen herumtrollt, der richtige Interview-Partner für solche heise-Artikel? Natürlich, denn beide schauen nicht genau genug hin. Felix steht ganz offen zu seiner laxen Art. Der Fehler liegt bei heise, indem sie glauben, jemand wie Fefe wäre eine seriöse Quelle.

Tobias Engler stellt Felix als "Sprecher des Chaos Computer Clubs" vor. Das sieht Felix allerdings anders. Es ist kein gutes Zeichen für hochwertige Recherche, wenn man nicht mal weiß, wen man da interviewt.

Speicherschutz

Felix moniert, es hätte vor OS X bei Apple keinen Speicherschutz gegeben. Felix behauptet auch, da wäre Windows 95 schon weiter gewesen. Das stimmt nicht, denn als richtiges Unix hatte A/UX das. Leider war A/UX kein Markterfolg, aber im Prinzip konnte es von 1988 bis 1995 schon das, was OS X später auch bot: Unix- und klassiche Mac-Programme zeitgleich zu nutzen. Und Speicherschutz sieben Jahre vor Windows 95. Es sieht so aus, als würde Fefe einen ebenso schlechten Start hinlegen, wie Tobias – ein Traumpaar.

Unix

Felix, der offensiver Vertreter von GNU/Linux ist, versteigt sich zu dieser Aussage: "Ein bloßer Unix-Unterbau garantiert jedenfalls noch keine Sicherheit gegen Hacker." Das sollte er besser wissen: Wie ist das mit Benutzern, die ohne Systemrechte arbeiten, und strenger Benutzertrennung bei Prozessen und Dateien? Das schützt andere Benutzer und das System. Außerdem ist OS X ein UNIX und hat nicht nur einen "Unix-Unterbau".

DEP

Felix reklamiert weiter, daß OS X DEP erst seit 2006 unterstützt und Microsoft Windows und GNU/Linux das schon früher hatten. Dazu ist zu sagen: Die frühen Versionen emulierten DEP nur in Software, was nicht so wirksam ist. Wirklich sinnvoll ist es nur, wenn die CPU das anbietet. Und das waren halt erst die G5s, wenn sie im 64-Bit-Modus laufen, und die ersten Intel-Macs. Apple hat also DEP so früh wie möglich eingebaut, obwohl es Windows wie oben beschrieben deutlich nötiger hat. Übrigens wird DEP aus Kompatibilitätsgründen auf Windows nur selten für 32-Bit-Programme verwendet. Und so kommt es, daß DEP von OS X und seinen Programmen inzwischen häufiger eingesetzt wird als auf Windows, weil hier 64 Bit normal sind und 64 Bit sich bei Windows noch nicht so durchgesetzt haben.

Bemühen um Sicherheit

Dann vermutet Fefe, Microsoft würde Sicherheitsprobleme ernster nehmen, weil sie angeblich zwei Gebäude mit Leuten füllen könnten, die sich um Sicherheit sorgen. Das hat, wie man meiner Einführung entnehmen kann, auch seine Berechtigung in der anfälligen Architektur. OS X ist jedoch schlauerweise nicht völlig proprietär wie Windows, sondern basiert auf sehr viel Software, die auch in anderen verwandten Betriebssystemen seit langer Zeit eingesetzt wird. Damit kümmert sich letztendlich nicht Apple allein um die Sicherheit des Systems, sondern diverse andere weltweit auch noch. In Summe sind das locker mehr als die zwei Hütten voll von Microsoft-Leuten.

Wie wir in den anderen Artikeln noch feststellen werden, legt Tobias unheimlich viel Wert auf die Meinung von Charly Miller.

Charly Miller schätzt Microsofts Bemühen um Sicherheit allerdings anders ein als Fefe:

Es erstaunt mich, daß Microsoft so viele kritische Fehler zu beheben hat. Sie versuchen anscheinend nicht halb so intensiv, sichere Software auszuliefern, wie sie uns glauben machen wollen.

It amazes me when MS has so many critical bugs to patch. They must not try to ship secure software half as hard as they lead us to believe.

Schnelligkeit bei Fehlerbehebungen

Fefe moniert, Apple wäre langsam beim Beheben konkreter Sicherheitslücken und führt als Beispiel ein Java-Problem an, was drei Monate länger als bei Sun gedauert hat. Dazu ist zu sagen, daß Sun alle Plattformen mit Java versorgt, Apple jedoch bis vor kurzem alle Anpassungen an Java selbst machen mußte. Und das passiert halt erst, nachdem die Referenz von Sun korrigiert wurde.

Daraus zu schliessen, Apple wäre langsamer als etwa Microsoft ist absurd, denn niemand benötigte länger zum Schließen von Sicherheitslücken als Microsoft. Beispiele:

Solche Microsoft-Rekordzeiten kann niemand überbieten. Von schneller Behebung und Sicherheit braucht man im Zusammenhang mit Microsoft daher überhaupt nicht reden.

Schwere der Lücken besorgniserregend

Kommen wir nun zum Hintergrund der Schlagzeile für diesen heise-Artikel: Felix prangert einen Fehler in der Airport-Extreme-Basis-Station an, der das Gerät abstürzen lassen kann. Ist das etwas besonderes? Nein, denn jeder Fehler in einer Geräte-Firmware führt potentiell zum Absturz, weil dort alles zum Systemprogramm gehört.

Und Felix, Dir ist schon klar, daß die Basis-Station nicht mit OS X läuft? Dieser Fehler also absolut gar nichts mit Macs zu tun hat?

Außerdem ist so etwas wie die Sieben-Jahre-System-Übernahme-Lücke oben in Windows um Längen besorgniserregender.

Und diese Art von Fehler sähe für Experten mehr als peinlich aus, schwadroniert er weiter, und die sollten an sich seit der Jahrtausendwende ausgestorben sein. Ehrlich? Fehler im Netzwerk-Stack wirken sich auch bei Windows auf die Systemstabilität aus. Und das Beispiel oben erlaubte sogar die volle Systemkontrolle über Windows.

Im November 2011 wurde auch noch ein Bug im TCP/IP-Stack von Windows öffentlich, der sich ausnutzen ließ, indem man bestimmte UDP-Pakete auf einen geschlossenen Port von Windows sendet. Der Angreifer konnte damit Code mit Systemrechten über das Netzwerk ausführen ohne Mithilfe eines Users. Diese Art von Fehler ist also auch 11 Jahre nach der Jahrtausendwende nicht ausgestorben.

Was soll also diese Schlagzeile? Die Benutzer verunsichern? Umsatz erzeugen? Vermutlich.

Und bezüglich des "unsicheren" IPsec-Fehlers: Der führte im schlimmsten Fall zur Nichtfunktion des Dämons. Dadurch wird das System nicht zwangsläufig unsicher. Wenn wir solche Fehler für Windows mitzählen wollen, könnten wir eine Artikelserie starten. Die wirklich kritischen Fehler behebt Apple in der Regel recht flott.

Zu der Stelle über den IMAP-Server Dovecot habe ich unten etwas geschrieben.

Dokumentierte Bug-Fixes

Die Advisories, die Apple zu ihren geschlossenen Lücken herausgibt, sind nach Industriestandard recht brauchbar, da werden die einzelnen Probleme explizit aufgelistet.

Apple dokumentiert jeden gefixten Fehler öffentlich. Microsoft patcht gerne auch heimlich und berichtet nicht über jeden behobenen Fehler. Dadurch ensteht bei vielen Laien der falsche Eindruck, Microsoft hätte weniger Bugs in seiner Software und OS X wäre fehlerhafter.

Finale

Die Abschlußfrage an Fefe war, ob er konkrete Schadensfälle von Malware auf OS X in Unternehmen oder im privaten Bereich kennt. Antwort: Nein.

Das einzig besorgniserregende an diesem Artikel ist seine Qualität. Er kann nicht halten, was die Schlagzeile versprochen hat.

Gedruckte Version

In der Mac&i wurde der gleiche Artikel 2011 in Heft 1 auf Seite 138 veröffentlicht, allerdings gekürzt. Und der befragte Felix von Leitner beschwert sich darüber auf seiner Seite mit den Worten: "Die gedruckte Version sieht stärker nach Bashing aus als es das ursprüngliche Interview hergibt. Die müssen halt auch auf ihre Quote gucken."

Das kann ich so stehen lassen.

0.11.4.2 heise.de: "Der Mac ist angreifbar"

In diesem Artikel stellt Ole Meiners Fragen an Andreas Marx von einer Sicherheitsfirma aus Magdeburg.

Vermißte Fragen

Die Schlagzeile ist noch nicht einmal sinnvoll, denn angreifen kann man alles. Die erste sinnvolle Frage wäre, ob man damit überhaupt Erfolg hat, und wenn ja, welche Prozesse man unter seine Kontrolle bringen kann: Einen des Benutzers oder alle eines Benutzers oder sogar Systemprozesse? Die zweite sinnvolle Frage wäre, wie lange das Schadprogramm auf dem Rechner überlebt in Abhängigkeit davon, wie tief es sich im jeweiligen System einnisten kann. Der Angreifer hat dank Nutzern mit Systemrechten und dem völlig unübersichtlichen System, siehe Registry, auf Windows einfach schon immer mehr Möglichkeiten gehabt als auf einem Unix.

Schädlings-Zähler

Es ist ein ziemlich lahmer Artikel, der auch wieder nichts mit der Schlagzeile zu tun hat. Er berichtet, daß seine Firma in 2010 bis zu 60.000 verschiedene Schädlinge pro Tag für Windows gezählt hat. Für alle anderen Plattformen inklusive mobiler Geräte jedoch nur circa 50. Keine näheren Angaben, wieviele für den Mac. Dabei wäre doch gerade diese Zahl wichtig für diese Schlagzeile. Also ein Schuß in den Ofen.

Machen wir einen Ausflug in die Natur: Was wird in der Natur am häufigsten und in der Regel erfolgreich angegriffen? Kranke und schwache Tiere. Ein Raubtier sucht sich immer das leichteste Ziel. Wie ist es mit Viren und Menschen? Viren greifen wahllos jeden Menschen an, den sie "treffen". Erfolgreich sind sie normalerweise jedoch nur bei Menschen, die ein geschwächtes Immunsystem habe und sei es wegen zu wenig Schlaf. Autoren von Computer-Viren greifen auch viel lieber die schwachen Systeme an, weil sie es dort leichter haben.

Die Bösen und der Marktanteil

Weiter berichtet er, daß es noch keine Baukasten-Systeme für Schädlinge für OS X gibt. Seltsam, denn bei seinem Beruf sollte ihm doch das Metasploit Framework ein Begriff sein. Und der Trojaner-Baukasten Weyland-Yutani ist ihm offenbar auch erst später durch die Presse bekannt geworden. Hätte er als Berufs-Sicherheits-Guru nicht eher davon Wind bekommen müssen?

Andreas widerspricht sich in seiner Einschätzung, ob OS X ein attraktives Ziel für Schadprogrammierer ist. Er sagt er:

Windows ist die vorherrschende Plattform und bleibt deswegen für die Entwickler von Schadsoftware das lukrativere Ziel.

Er traut aber diesem Marktanteils-Märchen, doch nicht so ganz. Zumindest vermutet er, daß die "Bösen" sich nichts von einem Märchen vorschreiben lassen. Denn zu der Handvoll Trojaner, die für OS X in all den Jahren aufgetaucht sind, sagt er:

Vielleicht wollten diese Kreise in Erfahrung bringen, wie stark sich solche Malware verbreitet, wie sehr sie sich auf Macs einnisten kann und wie schnell sie entfernt wird, um abzuschätzen, ob die Plattform ein lukratives Ziel darstellt.

Das ist eine brauchbare Aussage, die den Fragestellungen, die ich hier vermisse, etwas näher kommt. Leider bleibt er seiner eigenen Vielleicht-Frage die Antworten schuldig: Was kam denn nun nach diesen von ihm als Testballons angesehenen Trojanern? Nichts. Verbreiteten sich die Trojaner nennenswert auf der Plattform? Nein. Was ist nun nach seiner Logik daraus zu folgern? Daß die "Bösen" gemerkt haben, daß Schadprogramme auf OS X ziemlich schlechte Überlebens- und Verbreitungs-Chancen haben. Er schließt jedoch daraus, daß die Mac-Plattform angreifbar sei. Andreas, "angreifbar" ist alles. Außerdem nutzen Trojaner per Definition menschliche Schwächen aus und nicht Systemschwächen.

Trojaner

Zur rudimentären Erkennung der gängigsten Trojaner sagt Andreas, daß Apples Liste nur wenige Signaturen enhalte und seines Wissens nicht regelmäßig aktualisiert würde und damit "Augenwischerei" wäre. Solange nicht regelmäßig bislang unerkannte Varianten auftauchen, muß die Liste auch nicht aktualisiert werden. Wenn es nur wenige Schädlinge gibt, muß die Liste auch nur wenige Signaturen enthalten. Er weiß doch selbst, wie er oben berichtet hat, wie wenig Schädlinge für OS X immer so auftauchen.

Als im Frühling 2011 ein besser gemachter Trojaner in verschiedenen Varianten auftauchte, führte Apple eine tägliche Aktualisierung der Malware-Liste ein.

Marketing versus Sicherheit

Aus dem Umstand, daß Antworten von Apple nicht so selbstverständlich sind wie von Microsoft, schließt er, daß das Sicherheitsthema bei Apple nicht so ernst genommen würde. Andreas, Apple antwortet generell nur sehr selten, egal auf was. Wie ernst sie Sicherheit nehmen, sieht man an der sichereren Architektur (siehe meine Einleitung) und daß sie den Microsoft-Rekord von sieben Jahren offener Lücken noch nicht überboten haben. Microsoft steckt viel Geld in die Image-Pflege, hat aber ein anfälligeres System. Marketing löst keine Sicherheitsprobleme.

0.11.4.3 c't und Mac&i und c't kompakt Security: "Security paradox: Mac OS X hat Mängel, doch keiner nutzt sie aus"

Tobias Engler veröffentlichte den gleichen Artikel 2011 in Mac&i, Heft 1, auf den Seiten 134 bis 138 und in c't 2011, Heft 4, auf den Seiten 158 bis 160.

Im August 2011, einen Monat nach Erscheinen von 10.7 Lion, haben sie diesen Artikel über 10.6 Snow Leopard beinahe unverändert auch noch in der c't kompakt Security 03/2011 auf den Seiten 140 bis 144 veröffentlicht.

Aufreißer

Sein Aufreißer für den Artikel ist:

Apple ist langsam beim Schließen von Sicherheitslücken, inkonsequent bei der Implementierung neuer Sicherheitstechniken – und OS X unsicherer als Windows 7.

In der c't kompakt Security haben sie zusätzlich den MacDefender im Aufreißer erwähnt.

Das mit der Geschwindigkeit hatte ich oben bereits widerlegt und die sogenannten neuen Sicherheitstechniken wurden oben als unwirksam entlarvt. Aber schauen wir ruhig noch auf die Details, die er bringt.

Tobias redet von einem "Unix-Unterbau", dabei ist OS X ein UNIX. Nichts mit Unterbau. Er hat noch andere merkwürdige Ansichten.

Per se ist aber nahezu kein Stück Software sicher, fehlerfrei schon gar nicht.

Natürlich kann ein Programm sicher sein, indem es sicher entworfen wird und damit bestimmte Probleme von vornherein ausschließt. Microsoft hat allerdings schon Probleme beim Entwurf. Erst danach kommen Implementierungsfehler zum Tragen.

Unix, DAC und Root

Sein von Unix übernommenes Discretionary-Access-Control-Modell (DAC) – ein Rechtesystem für den Zugriff auf Dateien – gestattet jedem Anwender nur das Nötigste, sofern die Rechte auch richtig vergeben sind.

Nicht übernommen von, sondern ist selber eines. Die Rechte sind richtig vergeben ab Werk. Neben diesen POSIX-Rechten bietet es auch zusätzlich ACLs, die nur bei Bedarf zum Einsatz kommen. Windows bietet nur ACLs und keine POSIX-Rechte. Das ist ein Sicherheitsproblem, weil ACLs komplexer, unübersichtlicher und damit fehleranfälliger zu konfigurieren sind als die POSIX-Rechte. Die richtige Vergabe der Rechte ist damit eher unter OS X gewährleistet als unter Windows.

Allerdings reicht einem Angreifer eine einzige Schwachstelle in einem Programm aus, das mit root-Rechten ausgeführt wird, um seinerseits root-Rechte zu erhalten.

Das ist bei Windows noch nicht einmal nötig, da der typische Benutzer Systemrechte hat, eben auch mit beziehungsweise gerade wegen der UAC. Bei Windows ist also die Systemangriffsfläche neben dem System selbst auch jedes Programm unter dem typischen Benutzer. Als echtes UNIX hingegen minimiert OS X, die Angriffsfläche, indem möglichst wenig unter root läuft.

DAC als Sicherheitsfeature halten Experten für überbewertet.

Er nennt diese Experten nicht. Und die Experten, die ich befragt habe, beispielsweise Burt Janz, halten DAC wie POSIX-Rechte unter UNIX für die wichtigste Barriere gegen böswillige Benutzer oder Programme überhaupt. Denn ohne dies wäre jedes Unix Toast. ACLs sind übrigens eine feinere Implementierung von DAC.

Unter Windows nützt DAC allerdings nichts, weil der typische Benutzer Systemrechte hat. DAC wird also nicht überbewertet, sondern von Windows absurd eingesetzt.

DEP und ASLR

Danach stellt Tobias DEP und ASLR vor und erwähnt dabei nicht, daß auch ASLR auf 32 Bit prinzipiell nutzlos ist und auf 64 Bit den Angreifer nicht mehr abhält.

Bis ins letzte Jahr (er meint 2010) galt diese Technik (er meint DEP) in Windows 7 als „unknackbar“, seit letztem Frühling (2010) kann aber auch Microsofts System mit JIT-Spraying kompromittiert werden.

Dies ist mangelhaft recherchiert, denn wie man DEP (und ASLR) umgeht, wurde allerspätestens im Sommer 2008 auf der Black Hat in den USA gezeigt. Ich habe keine Ahnung, in welcher Höhle Tobias Engler diese Zeit verbracht hat, daß er dies alles verpassen konnte. Warum darf so jemand Artikel über Sicherheit verfassen, ohne die einfachen Fakten zu kennen? Kein Wunder, daß ihm die reale Sicherheit paradox vorkommen muß.

(Wegen ASLR:) der Angreifer findet keinen allgemeingültigen Einstiegspunkt.

Das ist auch nicht nötig, denn es gibt diverse Wege, wie er immer einen Einstiegspunkt findet. Halbwegs aktuelle Schadprogramme werden daher damit nicht aufgehalten.

Apple stattete erstmals OS X 10.5 mit beiden Schutz-Techniken aus.

Das stimmt so nicht, denn die erste x86-Version (10.4.4) von Tiger hatte bereits das, was woanders DEP genannt wird.

Zunächst schützte DEP zu Leopard-Zeiten nur den Stack, unter dem aktuellen Snow Leopard dann auch den Heap.

Das ist definitiv falsch, denn 10.5 Leopard setzt das NX-Bit auch für den Heap und exakt wie 10.6 Schnee-Leopard nur für 64-Bit-Programme.

Das NX-Bit kann zwar auch für 32-Bit-Programme gesetzt werden, was jedoch von der CPU nicht erzwungen wird und daher nicht viel bringen würde. Das NX-Bit gibt es im 64-Bit-Modus dieser CPUs beziehungsweise mit Hilfe der PAE. So bietet Windows Vista nur in den 64-Bit-Versionen hardware-gestützte DEP, in den 32-Bit-Versionen jedoch nur die noch leichter zu umgehende software-gestützte DEP. Der Grund sind Kompatibilitätsprobleme der Programme.

Microsoft Support:

32-bit versions of Windows Vista use a software-based version of DEP. 64-bit versions of Windows Vista support hardware-backed DEP.

Windows Vista und 7 haben DEP nur in ihren 64-Bit-Versionen für alle Programme aktiv, in den 32-Bit-Versionen werden standardmäßig nur "erforderliche Windows-Programme und -Dienste" damit versehen.

DEP in 32-Bit Windows 7

DEP steht nur 64-Bit-Prozessen wie Safari zur Verfügung – und damit auch nur auf 64-Bit-Macs.

Wie wir gerade oben gesehen haben, ist die Nutzung von DEP im meistens eingesetzten 32-Bit-Windows auch ziemlich mau. Auf der anderen Seite werden seit Jahren nur noch 64-Bit-Macs verkauft und die meisten Programme sind inzwischen 64-bittig.

Apple-User haben, da ihre Systeme überwiegend mit 64-Bit-Programmen laufen, gegenüber Windows, wo die meisten Programme noch 32-bittig im Einsatz sind, noch einen Vorteil: Mit 64 Bit werden Funktionsparameter über Register übergeben und nicht mehr über den Stack wie bei 32 Bit auf Intel x86. Wenn der Angreifer den Stack überschreibt, hat er auf 32-Bit-Intel die Kontrolle über alle Parameter einer Funktion. Bei 64 Bit nicht.

In der c't kompakt Security (Seite 142) ergänzt Tobias:

In die Entwicklung von OS X 10.7 hat sich Apple von diesen und anderen Sicherheitsexperten reinreden lassen und die Speicherrandomisierung deutlich verbessert.

Das hat Tobias (und viele andere da draußen) aber schön verdreht. Apple hat nicht nur allen registrierten Mac-Entwicklern, sondern zeitgleich auch einigen externen Sicherheitsleuten ermöglicht, die Prerelease-Version von Lion herunterzuladen und auszuprobieren, weil Apple glaubte, daß dies für diese Leute interessant sein könnte, weil sie vormals Sicherheitslücken an Apple berichtet hatten und Lion verschiedene Verbesserungen bei den Sicherheits-Gegenmaßnahmen enthält. Normalerweise haben nur die Mac-Entwickler Zugang zu Vorabversionen, um ihre Programme anpassen zu können. Grundlegende Eigenschaften des Systems werden nach diesem Zeitpunkt daher auch nicht mehr verändert.

Apple hat sich nicht reinreden lassen; die Verbesserungen bezüglich Speicherrandomisierung waren zu dem Zeitpunkt schon drin und alle anderen Security-Features auch.

Browser-Design, Prozesse und Sandkisten

Machtlos ist ein 64-bittiges Safari aber etwa beim Flash-Plug-in von Adobe, denn als 32-Bit-Prozess kann Flash nicht von diesem Schutz (er meint DEP) profitieren. An dieser Flanke ist Safari also verletzbar.

Das ist gleich in mehrfacher Hinsicht totaler Käse. Ein 64-Bit-Prozeß kann kein 32-Bit-Plugin laden. Flash ist ein sogenanntes "Netscape-style Plugin" und wird als "Out-of-Process Plug-In" in einem separaten Prozeß ausgeführt. Dadurch kann Flash weder andere Plugins noch Safari beeinflussen, wenn das Flash-Plugin durch einen Sicherheitsfehler kompromittiert werden sollte. Safari ist daher an dieser Flanke in keinster Weise verletzbar. Das gleiche gilt der Vollständigkeit halber auch für das QuickTime-Plugin.

Dino Dai Zovi hatte den Tobias übrigens in dem nachfolgend rezensierten Artikel über diese Art Plugins zumindest ansatzweise aufgeklärt. Allerdings ist die Information wohl nicht so ganz von Tobias verarbeitet worden. Das Wissen, was ihm in einem anderen Artikel präsentiert wird, ignoriert er hier also schon das zweite Mal: Oben den Artikel von seinem Kollegen und hier die Infos von Dino. Tobias möchte sich halt seine völlig aus der Luft gegriffene Verletzbarkeit "über diese Flanke" nicht vermiesen lassen. Mangelhaft recherchiert. Ungenügend verstanden.

ASLR unter Leopard und unter Snow Leopard ist identisch … Es gibt immer noch vieles, was nicht randomisiert wird.

Das ist richtig, aber die vermißte Technik ist so oder so nicht besonders wirksam.

Dann folgt etwas Bauchgefühl von Dino. Mutmaßen darf er nach Belieben. Natürlich macht die Fehlersuche weniger Arbeit, wenn man den Quellcode zur Verfügung hat wie bei OS X.

Jede QuickTime-Schwachstelle ist über den Browser angreifbar. (Charlie)

Das ist nicht so schlimm, weil das QuickTime-Plugin als "Out-of-Process Plug-In" in einem separaten Prozeß ausgeführt wird und nichts außerhalb beeinflussen kann. Hatten wir auch erst eben.

Google hingegen hat seinen Browser Chrome als Multi-Prozess-Modell gestaltet, trennt Rendering-Engine von Plug-ins – die Prozesse laufen jeweils in einem eigenen Sandkasten.

Googles Chrome basiert wie Safari auf WebKit. Google hat Chrome oberhalb der WebKit-API um Multi-Prozeß-Unterstützung erweitert. Also jenseits des Bereiches, den alle WebKit-Nutzer verwenden, nur für seinen Chrome-Browser. Andere WebKit-Programme können von diesem Chrome-Feature daher leider nicht profitieren.

Apple hingegen hat WebKit selbst um Multi-Prozeß-Unterstützung erweitert und stellt damit diese neue Funktionalität nicht nur jedem Browser, der auf WebKit basiert, zur Verfügung, sondern auch jedem Programm, was auf der WebKit-API aufbaut. Apple hat diese Weiterentwicklung von WebKit im April 2010 dem WebKit-Projekt zur Verfügung gestellt , nachdem sie daran längere Zeit unter dem Codenamen "WebKit2", ohne es an die große Glocke zu hängen, gearbeitet haben.

Damit ermöglicht Apple nicht nur Safari OS X Multi-Prozeß-Unterstützung, sondern auch jedem Konkurrenz-Browser und all den vielen Programmen, die auf WebKit basieren. Da WebKit2 aufgrund dieser grundlegenden Veränderungen eine zum WebKit1 inkompatibele API hat, kann man wohl erst ab OS X 10.7 damit rechnen, daß sie in beispielsweise Safari verwendet wird.

In den folgenden Abschnitten über Sandbox-Techniken verfällt Tobias dem Irrtum, die Integritätsstufen in Vista und 7 würden eine Sandbox darstellen. Dabei schreibt selbst Microsoft, daß der Windows Integritäts-Mechanismus nicht als Sandbox für Programme gedacht ist, weil er keine vollständige Isolationsbarriere bieten kann.

Der Internet Explorer arbeitet auf dem niedrigsten Level, was ihn am direkten Zugriff auf Ressourcen mit höherer Stufe hindert. Ohne einen speziellen Broker-Prozess könnte der Anwender nicht einmal Daten in seinen eigenen Benutzerordner schreiben. Für Safari würde so ein Schritt zu einem größeren Redesign mit spürbaren Entwicklungskosten führen.

Wie schon gesagt: Das können die Integritätsstufen gar nicht leisten. Und Safari und auch kein einziges anderes OS X-Programm benötigt für so etwas ein Redesign. Siehe dazu Google Chrome: Sandbox-Mechanismus von OS X rockt und Safari einsperren. Ich kann exakt einstellen, was Safari darf oder nicht darf. Und wenn man mag, kann man sogar eine Root-Shell einsperren. Apple setzt diese in Windows nicht verfügbare Sandbox-Technik auch schon eine Weile für Systemprogramme ein und wird das sicher auch auf Anwendungsprogramme übertragen.

Das Magazin Mac-Developer bestätigt diese Vermutung auf Seite 14 seines Heftes "3/2011 April, Mai" im Artikel "Dem Löwen ins Maul geschaut", wie ich nachträglich erst feststelle. Demnach empfiehlt Apple allen Entwicklern, Sandboxing zu verwenden und bietet in diesem Zusammenhang angeblich auch zusätzliche Programmierschnittstellen an. Dem Artikel zufolge unterliegen Programme mit diesem Sandboxing dann bestimmten generellen Einschränkungen hinsichtlich System und Kommunikation und können nur in einem eigenen Bereich im Dateisystem lesen und schreiben.

Das klingt gut, aber ich darf diesen Bericht zur Zeit leider nicht näher kommentieren, aber später schon in diesem Artikel.

Und um noch einmal auf das nötige "größere Redesign mit spürbaren Entwicklungskosten" für Safari einzugehen: Da Tobias sich ganz offensichtlich nicht näher mit der Materie beschäftigt, über die er schreibt, denn WebKit2, bei dem so etwas noch viel eleganter umgesetzt wurde als beim Internet Explorer, ist nicht von ihm bemerkt worden. Das Redesign und die Entwicklung sind also bereits passiert in "WebKit2" dank Apple – siehe oben; und auch im Safari von Lion vorhanden.

Patch-Geschwindigkeit und Open Source

Apple hinkt den Releases des WebKit-Projekts, das die Firma selbst ins Leben gerufen hat und mit Nokia, Google und anderen weiter entwickelt, teils um Wochen hinterher.

Was erwartet Tobias hier? Daß Apple jeden Tag die aktuellen Änderungen ungeprüft in Safari übernimmt und den Benutzer mit täglichen Updates nervt, die dann auch noch nicht richtig funktionieren?

In einem Sicherheitshinweis zu einem Patch für den freien IMAP-Server dovecot, der Bestandteil der OS X-Servervariante ist, spricht Apple gar davon, eine Lücke beseitigt zu haben, die nicht das Open-Source-Projekt betreffe. Felix von Leitner vom Chaos Computer Club analysiert: „Hier hat Apple also ein an sich sicheres Projekt unsicherer gemacht."

Wenn Tobias und Felix bedenken würden, daß Apple die Open-Source-Projekte natürlich nicht 1 zu 1 ungeändert übernehmen kann, sollte es sie nicht wundern, daß auch dabei mal ein Fehler passieren kann. Was soll diese weltfremde Darstellung?

Besondere Eile bei der Beseitigung von Sicherheitslücken hat Apple auch in der Vergangenheit nicht gezeigt. Erst mit Mac OS X 10.4 „Tiger“ konnte der Anwender ab 2005 den virtuellen Speicher verschlüsseln – in den knapp fünf Jahren davor tummelte sich sein Anmeldepasswort im Klartext in der Auslagerungsdatei.

Das ist richtig Bild-Zeitungs-Niveau, denn die Auslagerungsdatei kann nur von Root überhaupt gelesen werden. Wenn man jedoch Root ist, dann braucht man die Paßworte der Benutzer eh nicht mehr und kann sie sogar neu vergeben. Und wenn jemand Deinen Rechner klaut, dann braucht er keine Paßworte suchen. Einzig und allein eine Verschlüsselung des Home-Verzeichnisses schützt dann noch die privaten Daten. Und das bietet Apple ebenfalls seit Jahren mit dem System. Es soll andere Plattformen geben, bei denen muß man dazu Dritt-Software bemühen.

In der c't kompakt Security (Seite 143) erhöht Tobias die selbstrecherchierte Anzahl von Malware auf 85 (von 70), indem er 15 Versionen des MacDefender dazurechnet. Apples Malware-Erkennung in Lion kommt allerdings mit 2 Varianten aus, um alle Varianten abzufangen. In einer Extra-Box erwähnt er allerdings lobend, daß Apple schnell reagiert habe mit dem Einbau automatischer Malware-Signatur-Updates.

Tobias Fazit

Anschließend bringt er Ausschnitte aus einem Interview mit einer deutschen Sicherheitsfirma, auf das ich oben schon separat eingegangen bin.

Im Fazit summiert er dann seine obigen Fehler und hält Windows 7 für sicherer. Dabei ist das einzige, was Microsoft in Punkto Sicherheit besser macht als Apple, die Pressearbeit, in der sie den Journalisten leicht verdaulich verkaufen, was sie für Sicherheit halten. Apple ist dagegen bei der Dokumentation gefixter Bugs viel gesprächiger. Wenn man sich tief und lange mit dem Thema beschäftigt, wie ich es seit vielen Jahren mache, dann kann man sehr leicht Marketing und reale Sicherheit unterscheiden. Tobias konnte das hier nicht.

Das System wäre nur sicher, weil es nicht angegriffen würde. Nun, wie man hier und meinen anderen Artikeln nachlesen kann, hat OS X einiges mehr an realer (und orthodoxer) Sicherheit zu bieten als Windows. Windows wird mehr angegriffen, weil es geht.

In der c't kompakt Security (Seite 144) ergänzt Tobias am Schluß, daß Apple mit Lion einige Sicherheitsaspekte (er meint die Mitigations) in OS X verbessert habe, weil das System gerade mehr angegriffen würde. Damit meint er den MacDefender. Das ist schon allein aus dem Grund völliger Humbug, weil Lion beim Auftauchen von MacDefender praktisch fertig war und die verbesserten Mitigations eingebaut waren. Das, was aufgrund von MacDefender ergänzt wurde, ist die automatische Aktualisierung der Malware-Signaturen, die jedoch ebenso in 10.6 Snow Leopard eingeführt wurde.

Tobias erwähnt allerdings leider nicht, daß Charlie und Dino ihre Meinung geändert haben und Lion für viel sicherer als Windows halten. Das ist seltsam, denn wenn es darum geht, Mac OS X schlecht aussehen zu lassen, zitiert er die beide gerne.

In der c't kompakt Security (Seite 144) ergänzt er noch eine Box über Lion. In dieser behauptet er wieder, die (frei zitiert) "kritische Begutachtung durch weitere Sicherheitsexperten habe sich offensichtlich gelohnt, da ASLR beispielsweise deutliche Fortschritte gemacht habe". Tobias, die Jungs durften sich die Prerelease-Version ansehen und ASLR war zu dem Zeitpunkt schon so drin. Dino und Charlie hatten sich begeistert nach dem Ausprobieren der Prerelease-Version geäußert; keine Kritik. Außerdem wäre es zu diesem Zeitpunkt zu spät gewesen, solch grundlegende Änderungen am System und den Entwicklungswerkzeugen und den mitgelieferten Programmen vorzunehmen, denn die Mac-Entwickler sollen anhand dieser Prerelease-Version ihre Mac-Programme anpassen.

In dieser Box bringt er dann auch noch ein paar wunderschöne Schnitzer:

Unter Snow Leopard kamen nur 64-Bit-Systeme auf Wunsch in den Genuß (von No Execute für Daten).

Nicht auf Wunsch, sondern standardmäßig. Wir sind hier nicht bei Windows.

Stark verbessert zeigt sich ebenso die Sandbox, die nun unter dem Namen "App Sandboxing" Furore machen will.

Apple hat eine API auf höherer Ebene eingeführt, die das Verwenden von seit 10.5 systemprivat vorhandenen Sandbox-Funktionen überhaupt erst offziell anbietet und zudem komfortabel einsetzbar macht für Userland-GUI-Apps.

XPC ist eine Weiterentwicklung …, die sich am Model-View-Controller-Muster (MVC) orientiert und im Zusammenspiel mit der App-Sandbox besonders effektiv sein soll, um Threads rechtemäßig abzugrenzen.

MVC ist zwar toll, hat aber nichts mit XPC zu tun. Hier geht es um das Aufteilen von Programm-Funktionalität. Außerdem sollen nicht Threads abgegrenzt werden, sondern XPC-Prozesse. Und es geht nicht um unterschiedliche Rechte, sondern um unterschiedliche Sandboxen für XPC-Prozesse. Mehr dazu hier.

Transforms bauen auf Grand Central Dispatch auf.

Was hast Du Dir da nur zusammengeschusselt, Tobias? Der Lebenszyklus von XPC-Prozessen baut auf Grand Central Dispatch auf. Transforms bauen auf Core Foundation auf.

0.11.4.4 Mac&i und c't kompakt Security: "Apple muß Sicherheit verbessern"

Tobias Engler spricht mit Charlie Miller und Dino Dai Zovi in Mac&i 2011, Heft 1, auf den Seiten 139 bis 141. Einige Passagen, die in diesem Interview vorkommen, habe ich schon in der Rezension von 0.11.4.3 c't und Mac&i und c't kompakt Security: "Security paradox: Mac OS X hat Mängel, doch keiner nutzt sie aus" behandelt, weil er sie dort fast wortgleich bringt. Ich gehe dann hier nicht noch einmal darauf ein. Allerdings hat Tobias die Antworten von Dino und Charlie aus diesem Interview in dem obigen Artikel manchmal als seinen eigenen Text dargestellt und nur Teile den originalen Autoren zugeschrieben. Guter Stil ist das nicht.

Im August 2011, einen Monat nach Erscheinen von 10.7 Lion, haben sie dieses Interview über 10.6 Snow Leopard auch noch in der c't kompakt Security 03/2011 auf den Seiten 145 bis 147 veröffentlicht.

Narcissistic Vulnerability Pimps

Miller und Dai Zovi gelten als die führenden Mac-Sicherheitsexperten.

Charles Miller Charlie (Photo auf der "Blackhat 2010" aus der Sammlung von S. A. Ridley) und Dino sind anscheinend aufgrund ihrer Auftritte bei zwielichtigen Wettbewerben und ihres Buches die bekanntesten Apple-Hacker, aber ich halte sie weder für Sicherheitsexperten noch für führend, denn es gibt Leute, die sich nach meinem Dafürhalten besser mit der Sicherheits-Architektur von Mac OS X auskennen, beispielsweise Amit Singh und es gibt Hacker, die schon beeindruckendere Ergebnisse und Grundlagenforschung geliefert haben wie Vincenzo Iozzo oder Alexander Sotirov und Mark Dowd. So manchem Hacker geht es jedoch hauptsächlich um Publicity ohne Rücksicht auf die Sicherheit der betroffenen Anwender. Solche Hacker wurden daher erstmals 2010 als Narcissistic Vulnerability Pimps klassifiziert im Gegensatz zum "Security Researcher" wie sich diese Hacker gerne selbst nennen.

Das Mac-Hacker-Buch von Charlie und Dino weist übrigens gleich am Anfang einen interessanten Fehler auf.

Hacker Interview

Dino: Mac sicherer, weil der Marktanteil von Snow Leopard deutlich unter dem von Windows 7 liegt.

Mit so einer Logik wäre Windows 95 sicherer als Windows 7, denn sein Marktanteil ist ja geringer. Das gute alte Marktanteils-Märchen will einfach nicht aussterben.

Dino zur Verwundbarkeit: Es ist nach meiner Erfahrung um Klassen einfacher, Schwachstellen in OS X zu finden und auszunutzen als in modernen Windows-Systemen.

Das Finden ist erstens einfacher, weil ein großer Teil des Quellcodes in OS X offen liegt. Der Quellcode von Windows steht Dino nicht zur Verfügung. Und zweitens erfindet OS X nicht das Rad immer neu wie Windows, sondern nutzt bekannte, meist quelloffene Projekte anderer Unices. Ein Fehler dort ist dann auch ein Fehler hier.

Mit "einfacher auszunutzen" bezieht er sich vermutlich darauf, daß er hier weniger Probleme mit ASLR hat, was nach meiner Darstellung oben eine sowie recht nutzlose Technik ist.

Ob ihm ein Exploit leicht oder schwer fällt, ändert nichts an der generellen Verwundbarkeit eines Systems: Man kann einen Bug auf beiden Systemen ausnutzen. Allerdings führt das auf Windows eher zur Systemübernahme als auf OS X, weil der typische Windows-User Systemrechte hat, der auf OS X hingegen nicht. Die Verwundbarkeit eines Systems wird dadurch bestimmt, welche Auswirkungen das Ausnutzen eines Bugs hat, und nicht ob man dabei zwei oder drei Saltos machen muß.

Charlie: Unter OS X gibt es nach meiner Erfahrung wahrscheinlich mehr Browser-Schwachstellen als bei Windows-Browsern, weil jede Quicktime-Schwachstelle, von denen es viele gibt, über den Browser angreifbar ist.

Das Quicktime-Plugin findet sich normalerweise auch in Windows-Browsern. Außerdem ist die Quantität (Anzahl) nicht so sehr von Bedeutung wie die Qualität, wenn man bedenkt, daß jeder einzelne Exploit gegen Windows das System bedroht. Übrigens wird Quicktime gerade durch eine neue und radikal andere Version ersetzt.

Dino widerspricht Charlie: Angriffe gegen jüngere Windows-Systeme sind aber einfacher geworden wegen der Browser-Plug-Ins.

Plug-Ins sind für alle Browser ein Problem. Daher nutze ich für Safari auch ClickToFlash, um Flash nur auf vertrauenswürdigen Seiten laufen zu lassen.

Mac & i: Hat Apple denn zumindest die Data Execution Prevention unter Snow Leopard geändert? Charlie: Für 64-Bit-Prozesse wie Safari, ja. Aber 32-bittige Prozesse kommen nicht in den Genuß von DEP für den Heap.

Charlie, ich hatte Dich doch schon 2010 auf Deinen Fehler hingewiesen: 64-Bit-Prozesse hatten auch unter Leopard schon DEP für den Heap. Entweder ist dieses Interview total alt oder Charlie ist total vergesslich. Und zweitens, Charlie, 32-bittige Prozesse haben auf Intel keine hardware-gestützte DEP. Das ist daher nicht Apples Schuld. Okay, manche bieten software-gestützte DEP, aber die ist noch leichter zu umgehen.

Charlie: … Ein modernes Windows bietet im Vergleich (zu OS X) vollständige Randomisierung (ASLR) und vollständigen Speicherschutz (DEP).

In der Theorie und in der Werbung – vielleicht. In der Praxis: Nein. Das unterscheidet die Narcissistic Vulnerability Pimps, die hier interviewt wurden, halt von Leuten wie Alexander Sotirov und Mark Dowd. Die publizieren, daß aus verschiedensten Gründen (einer ist Kompatibilität) die hier angepriesenen (ohnehin praktisch nutzlosen) Mitigations("Abmilderungs")-Techniken bei Windows in der Praxis recht oft überhaupt nicht zum Einsatz kommen.

Bei OS X sieht es anders aus: Da, wo das System diese Techniken anbietet, werden sie auch in der Praxis meist tatsächlich von Programmen genutzt.

Daß bei 64-Bit Parameter nicht mehr über den Stack, sondern über Register übergeben werden, beurteilen sie als ein kleines Hindernis für Exploits: "Lediglich etwas mehr Arbeit." Das gleiche gilt auch für die Techniken, die sie hier so wichtig finden, obwohl sie so wirkungslos sind: Sie benötigen auch nur etwas mehr Arbeit.

Dino auf die Frage, warum Safari selbst im Gegensatz zu seinen Extensions nicht in einer Sandbox läuft: Safari wurde von Grund auf für so viele Funktionen ausgelegt, daß es schwierig ist, Regeln für die Sandbox zu entwerfen, die Malware ausbremsen könnten.

Das ist in der Tat ein Punkt, den ich auch von Apple erhoffe. Denn es ist nicht so schwer, Regeln für eine brauchbare Sandbox für Safari zu definieren, wie Dino sagt.

Dann ein komischer Satz von Tobias:

Flash scheint ja wirklich ein größeres Stabilitätsproblem zu sein und gehört in eine Sandbox.

Sandboxen dienen nicht der Stabilität. Separate Prozesse dienen der Stabilität. Und Flash läuft in Safari bereits in einem separaten Prozeß.

An einer Stelle ist der Artikel schon von der Wirklichkeit überholt worden: Dino beklagt sich, daß Apple nicht mit Leuten wie ihm zusammenarbeiten würde. Das ist nicht mehr so, denn Apple holt ganz offiziell die Meinung von verschiedenen Hackern zu 10.7 Lion ein. Unter anderem von Charlie und Dino.

Bezüglich der Einschätzung der Patch-Geschwindigkeit hatte ich ja oben Tobias kritisiert. In diesem Interview äußert sich Charlie dazu so wie ich. Er sagt, daß man nicht erwarten kann, daß für alle Produkte, die auf einer Library basieren, in der ein Bug entdeckt wurde, am gleichen Tag ein Bugfix veröffentlicht wird.

Code-Signaturen und eine zentrale Kontrolle wie bei iPhone-Programmen halten Charlie und Dino für eine wirksame Maßnahme gegen Malware. Und Apple bewegt sich auch auf dem Mac in diese Richtung. Meine Einschätzung zu Signaturen hatte ich ja deckungsgleich in meinem Viren-Artikel und im Sicherheits-Artikel beschrieben. Ich kann ja auch mal einer Meinung sein mit den Hackern.

Am Schluß spekuliert Charlie, daß Apples Kerngeschäft tolle Produkte sind und Sicherheit daher nicht so hohe Priorität habe. Das ist jedoch, wenn man sich den Aufbau von OS X ansieht, nicht der Fall. Hier wurde von Anfang an auf Sicherheit geachtet. Und Apple muß auch nicht erst wie Microsoft durch eine Sicherheitskrise gehen, denn bei Windows war Sicherheit anfangs tatsächlich kein Entwicklungsziel und es ist extrem schwierig, nachträglich Sicherheit "einzubauen". Charlie und Dino hatten das bei Browsern hinsichtlich Redesign angesprochen. Bei Betriebssystemen ist das jedoch eine Katastrophe. Denn, einen Browser fast ganz neu zu machen, ist nicht so schlimm, aber das ganze System? Also klebt Microsoft hier und dort das eine oder andere Sicherheitsfeature an das an sich unsichere Windows. Und wird dafür gelobt, weil sie es so laut tun. Auch wenn die neuen Features nicht viel bringen. Und selbst wenn DEP und ASLR die Sicherheit effektiv verbessern könnten: Was hilft es, wenn die grundlegende Architektur nicht sicher ist?

Sichere Tür

Eine Frage vermisse ich in dem Interview: Warum benutzen die beiden Hacker privat Macs? Ihnen ist Sicherheit wichtiger als anderen Leuten.

Mit Lion haben Charlie und Dino ihre Meinung geändert.

0.11.5 Fazit

Die Artikel-Sammlung in der Mac&i ist mit dem Anspruch angetreten, eine größere Analyse des Sicherheitskonzeptes von Mac OS X zu veröffentlichen. Diesem Anspruch sind sie nicht gerecht geworden, denn das Sicherheitskonzept von OS X wurde nicht besprochen, sondern hauptsächlich der Einsatz von zwei hippen Abmilderungs-Techniken, die erfolgreiche Angriffe nicht verhindern können. Am Rande noch Sandboxen und Fix-Geschwindigkeit, aber nichts zu den wirklich entscheidenden Grundlagen realer Sicherheit, dafür alles über vorgetäuschte Sicherheit. Sowohl heise als auch die interviewten Hacker haben sich zudem ein paar falsche Aussagen an Stellen geleistet, die mindestens auf schlechte Recherche schließen lassen.

Ich glaube, die Artikel sind folgendermaßen zustande gekommen: A: "Wir haben noch ein paar Seiten hinten im ersten Heft frei, was können wir da schreiben?" B: "Sicherheit ist noch nicht drin, und das kommt immer gut, also machen wir das." A: "Okay, aber wir haben zu wenig Plan für so viele Seiten. Eine könnten wir noch mit Marktanteil füllen, aber den Rest?" B: "Wir fragen ein paar Spezialisten." A: "Wen kennen wir denn da?" B: "Der Fefe kann doch immer total viel schreiben in seinem Blog und außerdem ist er im Chaos Computer Club Rocker-Präsi oder sowas." A: "Gut, aber geht es nicht noch ein bißchen internationaler? Gibt es keine Hacker aus dem Apple-Land, die gerne in der Presse sind?" B: "Klar, Dino und Charlie, die beiden lassen echt nichts aus seit Jahren." A: "Super, die fragen wir, aber was genau?" B: "Wir schauen, was Microsoft gerade als wichtig verkauft in Punkto Sicherheit, und quetschen die beiden Jungs darüber aus." A: "DEP und ASLR? Die werden doch ständig umgangen und nützen nicht wirklich was." B: "Das müssen wir ja nicht dazusagen." A: "Stimmt, die Mac-User kennen eh nur Photoshop und GoLive, das merken die eh nicht." B: "Und wenn MacMark das spitzkriegt?" A: "Dann sagen wir, er wäre ein Fanboy, das klappt immer."

Valid XHTML 1.0!

Besucherzähler

Latest Update: 11. September 2015 at 19:51h (german time)
Link: osx.macmark.de/osx_security-orthodox.php