6. Sicherheit, Viren, Würmer und Trojaner Inhaltsverzeichnis

Stichwort-Liste

• 6.0 Einleitung
• 6.0.1 Laienhafte Vermutungen
• 6.0.1.1 Scheinargument Marktanteil widerlegt
• 6.0.1.2 Trägheit der Masse
• 6.0.2 Technische Ursachen
• 6.0.2.1 Von jedem UNIX das Beste
• 6.0.2.2 Geboren für Mehrbenutzer-Betrieb und Netzwerk
• 6.0.2.3 Datei-Trennung
• 6.0.2.4 Prozeß-Trennung
• 6.0.2.5 Vergleich der Angriffsmöglichkeiten
• 6.0.2.5.1 Windows-Architekturfehler
• 6.0.2.5.1.1 Remote Procedure Calls überall
• 6.0.2.5.1.2 Monolithische Architektur
• 6.0.2.5.1.3 Unkontrollierte Anwendungs-Nachrichten
• 6.0.2.5.1.3.b Exkurs: Shatter-Attacks auf Windows Vista
• 6.0.2.5.1.4 Arbeitsverzeichnis im Suchpfad
• 6.0.2.5.1.5 Abschaltbare Signaturprüfung
• 6.0.2.5.1.6 Unsichere APIs und Protokolle
• 6.0.2.5.2 Installations-Risiken
• 6.0.2.5.3 Auswirkung eines Fehlers im Programm auf Windows
• 6.0.2.5.3.b Exkurs: Beispiel für unerwartete Netzwerkangriffe auf Windows
• 6.0.2.5.4 Auswirkung eines Fehlers im Programm auf Mac OS X
• 6.0.2.5.5 Architekturfehler versus Programmierfehler
• 6.0.2.5.5.b Exkurs: Design-Fehler schwer behebbar
• 6.0.2.6 Geprüfte Programmierung
• 6.0.2.7 Sicherheits-Server, -Agent und -Regelwerk
• 6.0.2.8 Signierte Programme: Leopard contra Viren
• 6.0.2.9 Quarantäne: Leopard contra Trojaner, darin: XProtect
• 6.0.2.10 Execute disable: Leopard contra Pufferüberlauf-Angriffe
• 6.0.2.11 Library randomization: Leopard contra return to libc
• 6.0.2.12 Sandbox: Sandkästen in Leopard
• 6.0.2.13 Gatekeeper: Weiße Liste
• 6.0.3 Cracker-Motivation
• 6.0.4 Umsorgt
• 6.0.5 Handlungsbedarf?
• 6.1 Viren
• 6.2 Würmer
• 6.3 Trojaner
• 6.4 Rootkits
• 6.4.1 Kernel-Module
• 6.5 Schutz
• 6.5.1 Eigentore
• 6.5.1.1 Schädliche Anti-Viren-Programme
• 6.5.1.2 Schädliche Daten-Schutz-Programme
• 6.5.1.3 Schädliche Firewall-Einstellungen
• 6.5.1.4 Schädlicher Tarnmodus
• 6.5.2 Fazit zu Schutzmaßnahmen
• 6.6 Panik und Helden
• 6.7 Dashboard-Lücke geschlossen
• 6.7.1 Fehler in 10.4.0
• 6.7.2 Fehler in 10.4.1 behoben
• 6.8 InputManager auf Leopard
• 6.9 Thematisch ergänzende Querverweise

6.0 Einleitung

Bei jedem Betriebssystem kann man allein aufgrund seiner Menge an Programmzeilen mit Fehlern (Bugs) rechnen.

Die Betriebssysteme unterscheiden sich jedoch bezüglich Sicherheit in zwei wesentlichen Aspekten:

• Wie stark sich Programmierfehler auswirken; das heißt, wie gefährlich Programmierfehler ausgenutzt werden können durch Schadprogramme.
• Ob die Systemarchitektur Schwachstellen hat. Manche Betriebssysteme bieten durch Architektur-Schwachstellen (broken by design) bestimmte Angriffsmöglichkeiten allein durch ihre gewollten, offiziellen Eigenschaften auch ohne Programmierfehler. Dies ist zu unterscheiden von Angriffsmöglichkeiten, die durch Programmierfehler entstehen, denn Programmierfehler kann man beheben, Architektur-Fehler nicht.

Ich werde darlegen, warum das UNIX-Betriebssystem Mac OS X keine durch ungeeignete System-Architektur bedingten Schwachstellen bietet, die ein Angreifer wirkungsvoll ausnutzen könnte.

6.0.1 Laienhafte Vermutungen

Die Leute, die oberflächliche Begründungen bevorzugen, und FUD-Kampagnen Gehör schenken, werden den Verbreitungsgrad eines Systems als Grund nennen. Die technisch korrekte Ursache ist jedoch etwas ganz anderes.

Siehe auch diese thematisch ergänzenden Artikel:

• Kapitel 0.10 Untersuchung verfügbarer Mac OS X Viren und Machbarkeits-Analyse. Sind Viren möglich und was sind die Bedingungen dafür?
• Kapitel 0.11: OS X - Security orthodox. Eine Beurteilung von heises "Security paradox"-Artikeln in c't, Mac&i und auf heise.de.
• Mac OS X 10.7 Lion: Der Löwenanteil an Sicherheit

6.0.1.1 Scheinargument Marktanteil widerlegt

Wenn der Verbreitungsgrad eine Rolle spielen würde, dann müßte der Apache Webserver deutlich mehr Sicherheitsprobleme haben als der Microsoft Internet Information Server, denn während zwei von drei Internet-Seiten auf dem Apache Webserver liefen und nur jede fünfte Internetseite auf dem Microsoft Internet Information Server, hatte der Apache Webserver deutlich weniger unter Sicherheitsproblemen aller Art zu leiden als der Microsoft Internet Information Server. Insbesondere die Würmer Code Red (IISWorm, und seine Nachfolge-Varianten) sowie Nimda, die jeweils Fehler im IIS nutzten in dieser Zeit, während es keine vergleichbaren Probleme mit Apache gab, sind hier zu nennen. Später, als Apache 64.91% hatte und der IIS auf 14.46% abgerutscht war, gab es die Lilupophilupop-Angriffe auf den IIS und seine ASP-Seiten, während der langjährige Marktführer Apache von vergleichbaren Angriffen verschont blieb. Es ist sogar offenbar so, daß der IIS mit seinem kleinen Martkanteil um 50% öfter angegriffen wird als der deutliche Marktführer. Damit ist das Scheinargument "Marktanteil" widerlegt.

Je leichter ein System angreifbar ist, desto öfter ist es Ziel von Attacken. Ein unsicheres Betriebssystem wird als leichtes Opfer immer einem sichererem vorgezogen.

Es gibt laut Apples Informationen Mitte 2011 über 54 Millionen Mac OS X-Installationen. Das Schein-Argument "Marktanteil" besagt, daß dies zu wenige wären, um dafür Schadprogramme zu schreiben.

Wenn das wahr wäre, dann hätte es den Witty-Wurm nie gegeben: Er griff bestimmte Sicherheitsprogramme an, von denen es nur 12000 Installationen gab. Er hat sie alle infiziert innerhalb von 45 Minuten.

Warum griff der Wurm eine installierte Basis von nur 12000 Instanzen an? Weil die angegriffenen Programme eine leicht ausnutzbare Sicherheitslücke hatten. Der Marktanteil spielte offenbar wieder keine Rolle.

Der Witty-Wurm hat keine Daten ausspioniert, er hat auch kein Botnetz aufgebaut, er hat keinerlei direkten Nutzen aus seiner Verbreitung gezogen. Er hat sich lediglich verbreitet und auf den infizierten Rechnern langsam und nach dem Zufallsprinzip die Festplatten gelöscht. Dieser Wurm war extrem effizient, sehr professionell und offensichtlich von Experten programmiert. Und all das, um eine kaum verbreitete Plattform anzugreifen.

Es genügt zwar ein einziges Gegenbeispiel, um eine These (hier: "Marktanteil als Grund für Schadprogramme") zu widerlegen, aber ich möchte noch ein weiteres schönes Gegenbeispiel bringen: Für das iPhone, welches ebenfalls mit einer Variante von OS X läuft, gibt es einen Wurm, der diejenigen iPhones angreifen kann, auf denen ein SSH-Zugang installiert wurde, der für root das Paßwort "alpine" verwendet. Das iPhone hatte zu dieser Zeit jedoch nur einen Marktanteil von circa 12% aller Smartphones und weniger als 3% aller Mobiltelephone. Der Anteil der angreifbaren iPhones war davon jeweils nur ein Bruchteil: Um den SSH-Zugang zu installieren, muß das iPhone erst jailbroken sein. Das waren weniger als 10% aller iPhones. Und von denen installiert nicht jeder SSH und von diesen wiederum nutzen nicht alle dieses Standardpaßwort. Damit sind also weniger als 1,2% aller Smartphones und weniger als 0,3% aller Mobiltelephone überhaupt angreifbar. Wenn der Marktanteil die Motivation für das Schreiben von Schadprogrammen wäre, dann hätte es diesen Wurm also überhaupt nicht geben. Es wird jedoch angegriffen, was verwundbar ist, egal wieviel Marktanteil es hat.

Der Marktanteil des Macs war zu der Zeit deutlich höher als der der angreifbaren iPhones, dennoch gab es dort so einen Wurm nicht. Der Grund ist, daß OS X auf dem Mac SSH standardmäßig zwar installiert, aber deaktiviert hat, und, daß root sich sowieso standardmäßig nicht einloggen kann und erst recht nicht mit einem allgemein vordefinierten Standardpaßwort. Beim iPhone wurde die Lücke durch eine unsicher konfigurierte nachträgliche Installation gerissen. Und diese Lücke wurde trotz extrem geringer Anzahl potentieller Opfer ausgenutzt.

Noch ein schönes Gegenbeispiel: Vor OS X nutzte Apple ein Nicht-UNIX-System für seine Macs. Das alte hatte System einen geringeren Marktanteil und eine kleinere installierte Basis als OS X, aber mehr Schadprogramme. Auch hier spielt offenbar der Marktanteil keine Rolle, sondern die Angreifbarkeit.

Und noch eins: Das iOS ist 2010 etwa 3,5mal soweit verbreitet wie das Android-System auf den Konkurrenz-Geräten (Quelle: Seite 23, lokale Kopie).

Allerdings gibt es für iOS, sofern es vom Benutzer nicht eigenhändig einiger Sicherheitsmechanismen beraubt wurde (Jailbreak), praktisch keine Schadprogramme. Zeitgleich leidet Android unter mehr als 50 äußerst bösartigen und effektiven Schadprogrammen. Zahlenmäßig lohnt sich zu der Zeit ein Angriff aber eher auf iOS-Geräte. Trotzdem gab sogar schon im Januar 2010 eine Banking Malware für Android.

Was sagt ein MCSE dazu?

Er sieht den Marktanteil ebenfalls nicht als Grund für die Schädlinge. Vielmehr sieht er sowohl den Marktanteil als auch die Schädlingsflut als Folgen der Offenheit und mangelnden Sicherheit von Windows.

6.0.1.2 Trägheit der Masse

Das oben widerlegte Scheinargument "Marktanteil" wird so gerne angeführt, weil es den Betroffenen das Gefühl gibt, daß sie die Situation nicht ändern können. Sie ziehen nicht in Erwägung, daß andere Systeme sicherer und sorgfältiger programmiert sind und eine sicherere Architektur aufweisen. Fehler und Schwachstellen, die nicht vorhanden sind, entstehen nicht plötzlich magisch dadurch, daß ein System weiter verbreitet ist.

6.0.2 Technische Ursachen

Es gibt diverse technische Ursachen, weshalb sich die Betriebssysteme in ihrer Anfälligkeit für Schädlinge unterscheiden.

6.0.2.1 Von jedem UNIX das Beste

Anders als bei Windows versucht nicht jedes UNIX ein eigenes Rad zu erfinden, wenn es schon bessere Räder gibt. Die Unices übernehmen erprobte Ideen und Implementierungen voneinander und profitieren wechselseitig von ihren Erfahrungen. Mac OS X ist da keine Ausnahme, ganz im Gegenteil: In Mac OS X findet man fast jedes gute Konzept wieder, was es in irgendeinem anderen UNIX gibt.

Mac OS X hat eine quelloffene Grundlage, die Darwin heißt. Darwin hat als Wurzel sehr viele andere quelloffene Projekte, zu denen unter anderem Mach gehört und 4.4BSD-Lite2, zu welchem FreeBSD, NetBSD und OpenBSD beitragen. OpenBSD hat zum Ziel, das sicherste Betriebssystem zu sein und wird auch als dieses anerkannt. Mac OS X verwendet einige Sicherheitstechniken, die OpenBSD auszeichnen.

6.0.2.2 Geboren für Mehrbenutzer-Betrieb und Netzwerk

UNIX ist für den Betrieb mit vielen gleichzeitigen Benutzern und als Netzwerk entworfen worden. Daher waren von Anfang an die entsprechenden Sicherheitsfragen zu beachten bei der Architektur. Bei UNIX gilt: "Das Netzwerk ist der Computer."

Andere Betriebssysteme, zu denen das marktbeherrschende gehört, wurden ursprünglich für Einzelplatznutzung ohne Netzwerk ausgelegt. Dort fehlte daher im Grundkonzept alles, was mit Sicherheit in Bezug auf Netzwerkbetrieb und mehrere gleichzeitige Benutzer zu tun hat. Bei Windows war lange Zeit oberstes Gebot, daß es keine Einschränkungen für Programme und Benutzer gibt: Jeder durfte alles mit allem.

Auch an der Ausführbarkeit von Dateien zeigt sich die frühe Berücksichtigung des Mehrbenutzerbertriebs: Bei UNIX ist ein Programm erst dann ausführbar, wenn das Ausführbarkeits-Bit gesetzt ist. Hierbei gibt es für den Besitzer der Datei, die Gruppe und andere Benutzer jeweils ein eigenes Bit. Die Ausführbarkeit hängt damit von der Identität des Benutzers ab und ob das zugehörige Ausführbarkeits-Bit gesetzt ist.

Bei Windows hängt die Ausführbarkeit eines Programmes von seiner Datei-Endung ab. Es gibt keine Ausführbarkeits-Bits, die bestimmen, ob es überhaupt gestartet werden kann und wer es starten darf. Bei UNIX ist es nie möglich, allein durch den Dateinamen über Ausführbarkeit zu bestimmen, denn es muß explizit ein Ausführbarkeits-Bit gesetzt sein.

Auf beiden Systemen gibt es ACLs, die unter anderem auch Ausführungsrechte für Benutzer regeln können. Allerdings sind ACLs wegen ihrer Komplexität für Fehlkonfigurationen anfällig und werden nicht auf allen Dateisystemen unterstützt, was besonders die vielen noch im Einsatz befindlichen Windows-Versionen bis XP betrifft. ACLs können dann zwar die Erlaubnis zur Ausführbarkeit regeln, bestimmen aber nicht über die Ausführbarkeit der Datei an sich.

6.0.2.3 Datei-Trennung

Generell sind UNIX-Betriebssysteme aufgrund ihrer typischen Beschränkung der Benutzerberechtigungen nicht so leicht von Viren zu befallen. Hier sind sowohl Prozesse als auch Dateien unterschiedlicher Nutzer sauber und sicher voneinander getrennt. So kann ein Virus, der unter einem normalen Benutzer oder Administrator läuft, nicht in andere Benutzer- oder System-Verzeichnisse schreiben.

Zugriffsbeschränkung auf Datei-Ebene

Dateisysteme von UNIX-Betriebssystemen verwenden schon seit ewigen Zeiten mindestens Zugriffsrechte auf Dateiebene. ACLs werden bei UNIX zusätzlich zur Verfeinerung der Zugriffesrechte eingesetzt; sie sind hier aber nicht notwendig, um Dateizugriffe einschränken zu können.

Als echtes Mehrbenutzer-Betriebssystem war UNIX schon Jahrzehnte darauf ausgelegt, fehlerhafte oder unautorisierte Datei-Zugriffe zu unterbinden. Daß das dann auch für Schadprogramme ein Hindernis ist, ist nur ein Nebeneffekt.

Administrator ungleich System

Unter Mac OS X ist ein Administrator nicht gleichmächtig mit dem System. Auf Systemverzeichnisse beispielsweise hat nur das System (root) Schreibrechte. Administratoren sind in der Gruppe admin und nicht in der System-Gruppe wheel, in der nur root Mitglied ist.

Unter OS X ist die Administrator-Gruppe ein Kompromiß zwischen "alles (root) oder nichts (normaler Benutzer)" wie er bei anderen Unices nicht zu finden ist, bei denen man entweder root oder nichts ist. Viele Aufgaben, die man nicht als normaler Benutzer erledigen darf, erfordern dennoch keinen root und die OS X-Adminstrator-Gruppe genügt dann. "Admins" auf anderen Systemen hingegen sind vergleichbar zu root und daher sollte die normale Arbeit damit vermieden werden. Die OS X Admins sind jedoch für die tägliche Arbeit gemacht. Der Sicherheitsgewinn, den ein normaler Benutzer bietet, ist bei anderen Systemen groß: Man fällt von root auf normal. Bei OS X ist man jedoch als Admin schon fast "normal", nur nicht ganz. Dafür muß man unter OS X so gut wie nie als root arbeiten und sich vor allem nie als root anmelden, wozu man jedoch auf anderen Unices und Windows (da heißt es anders) dann doch (gelegentlich) gezwungen ist.

Private Verzeichnisse

Kein normaler Benutzer und kein Administrator hat Zugriff auf die privaten Verzeichnisse der anderen Benutzer. So etwas ist unter Mac OS X und jedem anderem UNIX nur dem System (root) möglich.

Paßworte sind Standard

Legt man unter Mac OS X einen neuen Benutzer an, dann definiert man neben dessen Namen auch gleich dessen Paßwort. Läßt man das Paßwortfeld leer, wird man ausdrücklich darauf hingewiesen, daß dies keine gute Idee wäre, weil sich dann jeder anmelden könnte.

Im Normalfall hat man also keine Benutzer ohne Paßwortsicherung unter Mac OS X.

6.0.2.4 Prozeß-Trennung

Auch sind bei UNIX-Betriebssystemen unterschiedlich privilegierte Prozesse besser voneinander getrennt. Insbesondere laufen alle Prozesse aus Prinzip mit möglichst minimalen Berechtigungen. Werden besondere Rechte erforderlich, dann wird die Arbeit an einen sehr kleinen separaten Prozeß delegiert. Die geringe Größe eines solchen Spezialprozesses macht seine sichere und fehlerfreie Programmierung leicht.

Beim zur Zeit marktbeherrschenden Betriebssystem ist das genau andersherum: Dort läuft jeder Prozess mit maximalen Berechtigungen (ein Windows-Administrator ist gleichmächtig wie System) und geringere Rechte sind die Ausnahme (und nicht die Regel).

Unwichtige Prozesse sind in der Lage sogar Systemprozesse zu steuern (siehe Windows-Architekturfehler, Punkt 3 und Shatter-Attacks auf Windows Vista). Und man macht sich nicht die Mühe, ein Programm in mehrere kleine Programme aufzuteilen, um sicherheitsrelevante Aktionen nur in einem kleinen Spezialprogramm zu verwenden. Daher läuft das gesamte Programm und, was es nochmals verschlimmert, alle von ihm verwendeten Programmbibliotheken, als hochprivilegierte Prozesse, wenn auch nur ein kleiner Anteil hohe Rechte benötigt. Der gravierende Sicherheitsaspekt hierbei ist, daß man für die sichere und fehlerfreie Programmierung des gesamten Programms und der gesamten verwendeten Bibliotheken nicht garantieren kann. Eine Lücke in einem dieser Teile genügt, um das gesamte System anschließend zu übernehmen.

Was bei UNIX undenkbar ist, ist bei Windows Normalität: Alles arbeitet als Windows-Administrator, der einem UNIX-Root entspricht.

Ein Administrator von Mac OS X hingegen ist nicht Root. Und ein Administrator muß, wenn er systemrelevante Dinge tun will, sich nochmals authentifizieren mit Paßwort. Man kann nicht mit einem Klick das System ändern.

Ein Schadprogramm unter einem Benutzer in Mac OS X ist daher sehr eingeschränkt darin, was es tun und beeinflussen kann. Unter dem bei den Autoren von Schadprogrammen als Ziel sehr beliebtem anderen Betriebssystem hingegen hat solch ein Programm unter einem Benutzer alle nur denkbaren Möglichkeiten; es ist ein Paradies für Schadprogramme.

6.0.2.5 Vergleich der Angriffsmöglichkeiten

Die Betriebssysteme haben schon aufgrund ihrer Architektur Unterschiede darin, wie sie angegriffen werden können.

6.0.2.5.1 Windows-Architekturfehler

Die folgenden Quellen zeigen Architekturfehler von Windows und warum durch Nachbesserungen in so einem Fall nicht mehr viel zu retten ist:

Im folgenden gehe ich auf die wichtigsten Beispiele für schwere Fehler bezüglich Sicherheit in der Architektur von Windows ein:

6.0.2.5.1.1 Remote Procedure Calls überall

Das Anbieten von Netzwerkzugriffen auch auf Nicht-Netzwerk-Programme, indem Remote Procedure Calls (RPCs) zu häufig und an unnötigen, unangebrachten Stellen (eben in Nicht-Netzwerk-Programmen) verwendet werden.

6.0.2.5.1.2 Monolithische Architektur

Die Vermischung von Programmen untereinander und mit dem System. Ein Fehler in einem Programm wirkt sich auf andere Programme und das System aus. Denn Windows ist monolithisch, weil es zuviele Funktionen in den Betriebssystem-Kern integriert, wo sie unnötig viel Schaden anrichten können. So gehören beispielsweise Graphikroutinen (nicht zu verwechseln mit "Graphik-Karten-Treibern") nicht in den Kern (wie bei Windows), sondern in eine höhere Schicht (wie bei den Schichten (aktueller Link) von Mac OS X zu sehen ist, wobei beispielsweise die Lage von "Quartz" zu betrachten ist). Windows hat keine sauber getrennten Schichten, sondern ist monolithisch, was Viren leichter zu Systemrechten verhilft.

Microsoft hat nicht die technisch beste Architektur im Sinn, sondern läßt sich von anderen Motiven leiten, die der Sicherheit schaden:

Bekanntestes Beispiel für die Nicht-Trennung von Programmen und System ist der Internet Explorer, der so tief mit Windows verwoben wurde, daß er inzwischen untrennbar damit verbunden ist. Microsoft hat das sogar vor Gericht bewiesen und ein Windows ohne diesen Webbrowser ist eine Sonderanfertigung. Das Motiv war hier, einen Wettbewerbsvorteil gegenüber anderen Anbietern von Webbrowsern zu haben. Auf Kosten der Sicherheit.

Ein zweites Beispiel ist die oben angesprochene harte Verdrahtung des GUI im Adreßraum des Betriebssystemkerns nach Version 3.5 in Windows NT. Das Motiv war hier eine Geschwindigkeitssteigerung. Auf Kosten der Sicherheit, weil damit ein Angriff auf das GUI zur Übernahme des Systems führen kann. Das Problem ist anscheinend auch in neueren Version noch grundsätzlich vorhanden.

Ein drittes Beispiel ist die harte Verdrahtung des Webservers im Adreßraum des Betriebssystemkerns in späteren Versionen von Windows NT. Das Motiv war hier, die Geschwindigkeit zu steigern, um zu versuchen, so schnell wie UNIX-basierte Webserver zu werden. Das geht wie oben ebenfalls auf Kosten der Sicherheit, weil ein erfolgreicher Angriff auf den Webserver damit zur Systemübernahme führen kann.

Es ist offensichtlich, daß eine monolithische Architektur zwingend zu Sicherheitsproblemen führt, weil die Sicherheitsgrenzen innerhalb des Systems dadurch praktisch wegfallen.

6.0.2.5.1.3 Unkontrollierte Anwendungs-Nachrichten

Die Möglichkeit, daß Programme sich zu unkontrolliert ohne Authentifizierung gegenseitig Anweisungen (mit dem Windows messaging system) schicken können. Denn auch für Windows Vista gilt weiterhin: Wenn ein Programm so eine Nachricht erhält, hat es keine Möglichkeit, festzustellen, wer der Absender ist und ob der Absender überhaupt berechtigt ist, ihm Nachrichten zu schicken. (Außerdem sind auch Shatter-Attacks auf Windows Vista möglich.)

6.0.2.5.1.3.b Exkurs: Shatter-Attacks auf Windows Vista

Die Integritätsstufen von Vista lassen sich allerdings umgehen. Selbst ein Prozeß auf niedrigster Stufe kann Steuer-Nachrichten an höhere Prozesse schicken. Damit ist die wichtigste Sicherheits-Neuerung in Windows Vista praktisch wertlos.

Die UAC und die UIPI in Windows Vista beheben nicht den Architekturfehler, sondern legen eine scheinbare Sicherheitsfunktion darüber, die jedoch das weitere Ausnutzen nicht verhindern kann. Anders ausgedrückt ist Windows Vista wie seine Vorgänger "broken by design", aber mit dem Unterschied, daß es auf einer architekturbedingten Schwachstelle neue Flicken (UAC und UIPI) hat, die nicht richtig funktionieren.

6.0.2.5.1.4 Arbeitsverzeichnis im Suchpfad

Eher ein Design-Fehler, aber dennoch sehr unschön:

Bei Windows werden die Bibliotheken für Programme auch im aktuellen Arbeitsverzeichnis, also dem Verzeichnis, in dem man sich gerade befindet, gesucht. Dadurch können anstelle der Original-Bibliotheken ganz andere untergeschoben werden. Dies wird DLL- Spoofing genannt.

Sicher und korrekt wäre es, wenn Programme ihre Bibiliotheken nur aus Verzeichnissen laden, die gegen Veränderung durch beliebige Nutzer abgesichert sind. Typischerweise wären das das Verzeichnis des Programms selbst beziehungsweise die Verzeichnisse, in denen die Systembibliotheken liegen. Keinenfalls jedoch ein beliebiges Verzeichnis eines beliebigen Benutzers. Eine weitere sichere Möglichkeit wäre, den vollen Suchpfad fest zu definieren.

Dieses seltsame Verhalten besteht insbesondere auch beim Internet Explorer und wird schon seit einiger Zeit kritisiert:

Dieser Fehler ist vergleichbar mit einem, den UNIX-Anfänger gerne aus Bequemlichkeit begehen: Sie tragen die Variable für das aktuelle Arbeitsverzeichnis in ihren Suchpfad ein.

Bei Windows werden die Bibliotheken zur Laufzeit aus variablen Verzeichnissen geladen. Bei Mac OS X hingegen werden die Bibliotheken, die ein Programm benutzen möchte, aus fest vorgegebenen Verzeichnissen geladen, die das Programm vorgibt. Zur Laufzeit können diese Angaben nicht verändert werden, denn sie sind "hard-coded". Die zu ladenden Bibliotheken für beispielsweise TextEdit kann man sich mit otool -L /Applications/TextEdit.app/Contents/MacOS/TextEdit ausgeben lassen.

Der Sicherheits-Vorsprung von Mac OS X besteht in diesem Punkt darin, daß die Pfade zu den Bibliotheken schon beim Erstellen des Programms definiert werden während sie bei Windows zur Laufzeit gesetzt werden.

Dieser Design-Fehler besteht nicht nur bezüglich Bibliotheken, sondern auch für Programme, also exe-Dateien: Windows sucht das passende Programm standardmäßig zuerst in dem Verzeichnis, in dem die zu öffnende Daten-Datei liegt. Und das kann auch ein Netzwerkverzeichnis im Internet sein.

6.0.2.5.1.5 Abschaltbare Signaturprüfung

Noch ein Design-Fehler, der einen Sicherheitsmechanismus torpediert:

Neuere Windows-Versionen sollen Kernel-Mode-Code (beispielsweise Treiber) nur laden, wenn er mit einer von Microsoft abgesegneten Signatur versehen ist.

Der typische Windows-Admin-Benutzer kann diese Signaturprüfung jedoch abschalten, indem er einen Testmodus aktiviert, der praktisch beliebigen Code ungeprüft lädt. Ebenso kann das passende Malware. Dabei kann man auch unter Windows Vista und Windows 7 problemlos mit Standardeinstellungen auf seine dafür nötigen Administrator-Rechte zugreifen und alle Abfragen elegant by design umgehen.

6.0.2.5.1.6 Unsichere APIs und Protokolle

Würde Microsofts Betriebssystem weitgehend quelloffen sein wie das von Apple, dann hätten sie ein riesiges Problem. Wie sie selbst vor Gericht ausgesagt haben, können sie Windows nicht offenlegen, weil es APIs und Protokolle enthält, die bei Offenlegung ein Sicherheitsproblem wären. Es sind also wohlgemerkt nicht einmal Bugs nötig, um Windows in Gefahr zu bringen. Es ist "broken by design", weil es APIs und Protokolle nutzt, die unsicher entworfen wurden.

6.0.2.5.2 Installations-Risiken

Die Installation von Programmen erfordert unter Mac OS X keine Systemrechte und in der Regel kein Installationsprogramm. Die Installation ist ein einfaches Kopieren des Programmes nach /Applications, was Administrator-Rechte, mit denen man keine Systemdateien ändern kann (das kann nur root), voraussetzt, oder nach ~/Applications, also in das eigene Benutzerverzeichnis, was jedem Normal-Benutzer möglich ist.

Bei Windows Vista wird jedoch jedes noch so kleine Programm von einem Installations-Programm installiert. Selbst wenn ein normaler Benutzer ein Programm nur für sich installieren will, kommt er um ein Installation-Programm nicht herum. Wo liegt nun die Gefahr dabei? Windows Vista zwingt den Anwender, jedes Installations-Programm unter einem Administrator, welcher unter Windows Vista Systemdateien ändern kann, wozu er im schlimmsten Fall auf "OK" oder "Fortfahren" klicken muß, auszuführen. Das bedeutet, daß jedes Installations-Programm beliebig tief im Betriebssystem herumpfuschen kann.

Während also bei Mac OS X jeder Benutzer ein Programm installieren kann, ohne daß das System dadurch verändert werden könnte, birgt jede einzelne Programminstallation unter Windows Vista die Gefahr, daß das System manipuliert oder infiziert wird.

6.0.2.5.3 Auswirkung eines Fehlers im Programm auf Windows

Der entfernte Netzwerkzugriff auf fast alles und jedes unter Windows, gepaart mit der Vermengung von Programmen und System, führt in der Regel dazu, daß eine einfache Lücke in einem normalen Nicht-Netzwerk-Programm über das Netzwerk (dank RPC) ausgenutzt und das System kompromittiert (dank Vermischung Programm/System) werden kann.

6.0.2.5.3.b Exkurs: Beispiel für unerwartete Netzwerkangriffe auf Windows

Es fängt mit dem Architekturfehler an: Windows benötigt RPC (Funktionsaufrufe über das Netzwerk), selbst wenn kein Netzwerk da ist. Es ist nicht möglich, diese Netzwerkfunktion (RPC) abzuschalten.

Nun gibt es den "Microsoft SQL Server", eine Datenbank, die RPC benutzt. Da Microsofts Entwicklerwerkzeuge dazu ermuntern, den gleichen monolithischen Ansatz zu verfolgen, den Mircosoft selbst bevorzugt, findet man die SQL Server Engine auch in vielen Anwendungen, die gar kein Netzwerk benötigen. Diese normalen Schreibtisch-Anwendungen bieten auf diese Weise ganz ungewollt diverse Netzwerkdienste der "SQL Server Engine" an.

Unglücklicherweise hatte der SQL Server einen Fehler. Dieser Fehler ließ sich dank RPC nun über das Netzwerk ausnutzen. Und weil die SQL Server Engine in vielen anderen Nicht-Netz-Programmen verwendet wird, waren all diese normalen Programme nun auch per Netzwerk angreifbar und durch den SQL Server Engine-Bug ausnutzbar. Selbst Leute, die sich sicher schätzten, waren ungewollt erfolgreichen Netzwerkattacken ausgesetzt.

Diese unnötige Netzwerkfunktion in Verbindung mit Microsofts monolithischer Software-Philosophie machte den Wurm namens "SQL-Slammer" zu einem Schädling, der das Internet fast zum Erliegen brachte.

Damit ist es jedoch noch nicht zu Ende. Microsoft plant, die SQL Server Engine im zukünftigem datenbankbasiertem Dateisystem "WinFS" von Windows einzusetzen. Damit bekommen wir ein Dateisystem, das über RPC die Netzwerkdienste des SQL Servers auf jedem Windows ermöglicht. Eine Steilvorlage für Würmer.

Würde Microsoft RPC nur dort einsetzen, wo man es benötigt, hätte es den "SQL-Slammer" nie gegeben.

6.0.2.5.4 Auswirkung eines Fehlers im Programm auf Mac OS X

Ein verleichbarer Bug in einem Mac OS X-Nicht-Netzwerk-Programm könnte in der Regel nicht über das Netzwerk (dank RPC-Abstinenz), sondern nur lokal ausgenutzt werden und man kann damit in der Regel auch nicht das System übernehmen (dank sauberer Trennung vom System zur Laufzeit durch konsequente Schichtarchitektur und auf der Platte durch separate Verzeichnisse), sondern nur einen einzelnen Prozeß kompromittieren.

6.0.2.5.5 Architekturfehler versus Programmierfehler

Bei Windows war es jahrelang die Devise, daß jeder alles mit allem können soll; auch über das für lokale Kommunikation deplaziert eingesetzte RPC. Das wurde Windows im Zuge der globalen Vernetzung der Rechner zum Verhängnis: Nun konnten alle im Internet dem heimischen Rechner sagen, was er tun soll dank RPC. Ein klassisches Scheunentor.

UNIX hingegen, das von Beginn an auf Mehrbenutzerbetrieb und als Netzwerk ausgelegt war (das Internet besteht aus UNIX-Protokollen), hat die nötigen Architektur-Aspekte von Anfang an im Betriebssystem und den Programmen umgesetzt und hat darüber hinaus Jahre Vorsprung, was die Praxiserfahrung in all diesen Dingen angeht.

Man muß also zwischen einer schlechten Architektur des Systems, die grundsätzlich einen entfernten Zugriff auf fast jedes Programm und dann das System ermöglicht, und Bugs unterscheiden. Windows und seine Programme nutzen RPC, Remote Procedure Calls, an allen Ecken und Enden, auch an Stellen, wo es nicht nötig wäre. Das zusammen mit der Vermischung von Programmen und Systemprogrammen ist einer der Hauptgründe, warum Windows leicht entfernt über das Netz auf Systemebene übernommen werden kann.

Die Unices machen so etwas nicht. Allerdings können auch sie Bugs haben. Jedoch haben Bugs auf Windows aufgrund der schlechten Systemarchitektur (Stichworte Vermischung und RPC) fast immer kritische Folgen (systemweit und angreifbar über Netzwerk), bei UNIX wirken sich die Bugs aufgrund besserer Architektur (Trennung und kein unnötiges RPC), meist nicht so schwerwiegend (prozeßweit und lokal angreifbar) aus.

Es ist wichtig, zwischen Angriffsmöglichkeiten zu unterscheiden: Die einen sind architekturbedingt (und nicht behebbar), die anderen sind durch Bugs (die behebbar sind) möglich. Ferner wirken sich Bugs auf Windows durch die monolithische Architektur (siehe oben) fast immer auf das ganze System aus, bei UNIX nur begrenzt.

Auf Mac OS X kann daher das System nur durch Programmierfehler, die behebbar sind, kompromittiert werden. Bei Windows hingegen ist das System selbst falsch konzipiert und daher sogar ohne Programmierfehler kompromittierbar. Leider kann man eine grundfalsche Architektur nicht korrigieren; man kann sie nur komplett ersetzen.

6.0.2.5.5.b Exkurs: Design-Fehler schwer behebbar

Im Jahre 2001 wurde ein Fehler im SMB-Protokoll bekannt. Der Fehler ermöglichte die volle Übernahme des Systems per Netzwerk. Microsoft mußte in den folgenden sieben Jahren Windows nach und nach umbauen, so daß sie den Fehler im Jahre 2008 endlich beheben konnten. Vorher war das nicht möglich, weil ansonsten die meisten Netzwerk-Anwendungen funktionsunfähig gewesen wären. Betroffen waren alle Versionen von Windows 2000 bis einschließlich Windows Vista.

Dies war ein Design- kein Architektur-Fehler des Systems, aber man sieht daran, daß solche Fehler im Gegensatz zu normalen Bugs ein erhebliches Problem darstellen: Sie können über Jahre nicht behoben werden und stellen jahrelang eine Systemgefahr dar.

Bei Mac OS X finden sich zwar auch Bugs, aber diese sind leicht zu korrigieren, weil es eben keine Fehler im Design oder der Architektur sind.

6.0.2.6 Geprüfte Programmierung

Ein beliebtes Angriffsziel sind sogenannte Buffer-Overflows. Dabei werden Speicherbereiche über ihre geplante Grenze hinaus so verändert, daß es möglich wird, fremden Code einzuschleusen und auszuführen. Voraussetzung für solch einen Angriff ist, daß eine entsprechende Programmstelle ausgenutzt werden kann, die nicht mit der nötigen Sicherheit programmiert wurde.

In jahrelanger Arbeit wurden solche Schwachstellen aus OpenBSD entfernt, indem entsprechende Längenabfragen in die Standardprogramme von OpenBSD eingebaut wurden. Die anderen BSD-Systeme, inklusive Mac OS X, konnten von diesen Verbesserungen profitieren und gelten daher ebenfalls als relativ sicher.

Im Gegensatz dazu bietet Windows hier eine unglaubliche Fülle von Angriffspunkten: Erstens gilt die Implementierung des TCP/IP-Protokolls in Windows als schlecht und instabil. Und zweitens strotzt Windows nur so vor mangelhaften Längenabfragen (mögliche Buffer-Overflows), die man mit dem SoftIce-Debugger finden kann.

6.0.2.7 Sicherheits-Server, -Agent und -Regelwerk

Mac OS X verwendet ein Sicherheitsmodell, welches auf einer standardisierten Sicherheitsarchitektur basiert: CDSA. Dieses nutzt Mac OS X für Verschlüsselung, detaillierte Zugriffsberechtigungen, Benutzer-Identifizierung und sichere Datenspeicherung.

Betrachten wir die Zugriffsberechtigungen. Mit Hilfe der normalen BSD-Zugriffsberechtigungen, die die Zugriffsrechte auf Dateien (Verzeichnisse sind auch nur Dateien) für die Benutzer festlegen, kann man nur festlegen, ob jemand beispielsweise ein Programm starten darf oder nicht. Mit Hilfe der detaillierten Zugriffsberechtigungen, die durch den Sicherheits-Server, den Sicherheits-Agenten und die Regeldatenbank verfügbar sind, können zusätzlich feine Kontrollen und Unterscheidungen für beliebige Programmstellen vorgenommen werden.

Beispielsweise kann man damit festlegen, daß ein Benutzer bestimmte kritische Aktionen in einem Programm nur ausführen darf, wenn er sich dafür als berechtigte Person identifiziert, obwohl jeder Benutzer das Programm verwenden kann. Man beachte, daß dabei kein Benutzerwechsel stattfindet; das Programm wird weiter unter dem normalen Benutzer ausgeführt. Spezielle Bereiche des Programms werden allerdings nur ausgeführt, wenn man sich als berechtigt ausweisen konnte. Die Identifizierung kann auch schon im Voraus stattfinden und eine Verfallsdauer haben, wodurch verhindert wird, daß ständig Dialoge auftauchen. Die Identifizierung muß auch nicht zwingend als Dialog stattfinden, sondern könnte ebenso Chipkarten oder Fingerabdrücke und dergleichen nutzen. Die Identifizierung ist kein Benutzerwechsel, sondern dient lediglich dem Ausstellen einer Erlaubnis, vergleichbar einem Visum.

Ein Programm kann sich selbst beschränken, indem es den Identifizierungsdienst für bestimmte Akionen verwendet, was eine feinere Unterscheidung der Benutzer-Rechte ermöglicht, als es das BSD-Modell alleine oder die optionalen ACLs bieten. Außerdem kann der Start eines wie oben beschriebenen ausgegliederten kleinen Spezialprozesses, der unter höheren Rechten laufen soll, von einer geeigneten Identifizierung abhängig gemacht werden. In dem ersten Fall geht es um Selbstbeschränkung und im zweiten um Systembeschränkungen.

Das Programm erbittet vom System also eine bestimmte Berechtigung. Der Sicherheits-Server wird vom System informiert und dieser schaut in der Regeldatenbank nach und stellt fest, ob niemand, jeder oder nur bestimmte Benutzer die angefragte privilegierte Operation ausführen darf. Dann wird, falls nötig, der Benutzer um eine entsprechende Identifizierung gebeten. Da das Programm Paßworte nicht kennen soll, wird vom Sicherheits-Server ein getrennter Prozeß, der Sicherheits-Agent, aufgerufen, welcher die Benutzer-Identifizierung vornimmt.

Dadurch kann sichergestellt werden, daß kritische Programmteile nur kontrolliert ausgeführt werden. Außerdem kennt das Programm keine Paßworte, weil die Identifizierung vom Sicherheits-Agenten durchgeführt wird. Das Programm bekommt lediglich die Erlaubnis, die gewünschte Operation durchzuführen. Um welche Berechtigung es jeweils genau geht und welches Programm sie benötigt, kann man sich anzeigen lassen, indem man auf "Details" klickt in solch einem Identifizierungs-Dialog.

Damit stehen selbst einem angegriffenen und übernommenem Programm keinerlei Paßworte zur Verfügung und auch nicht die Möglichkeit, kritische Aktionen ohne Erlaubnis auszuführen.

Dieses Vorgehen erlaubt es auch, daß während man als normaler Benutzer arbeitet, es möglich ist, Systemeinstellungen vorzunehmen, die Administratoren vorbehalten sind, wenn man sich mit Name und Paßwort eines Administrators für diese Aktion ausweisen kann. Darüber hinaus können auch Administratoren noch einmal um Identifizierung gebeten werden, wenn sie bestimmte Aktionen durchführen.

Dieses Sicherheitsmodell ist feingliedriger und genauer, weil es unterschiedliche Privilegien nicht nur auf Programmebene (für Programme), sondern auch innerhalb der Programme, für beliebige Programmteile beachten kann. Und darüber hinaus ist dieses Modell sogar weniger nervig für den Benutzer, da es aufgrund der ausgestellten Genehmigungen, die bezüglich Verfallsdatum und Gültigkeitsbereich eingestellt werden können, den Benutzer mit weniger Dialogen belästigt.

6.0.2.8 Signierte Programme: Leopard contra Viren

Seit 10.5 Leopard haben alle Apple-Programme, auch die System-Programme, eine digitale Signatur. Drittprogramme sollen ebenfalls von ihrem Hersteller signiert werden. Jede Veränderung eines signierten Programms, beispielsweise durch einen dann enthaltenen Virus, macht die Signatur ungültig. Ob ein Programm eine gültige Signatur hat, kann man im Terminal überprüfen.

Verspätet hält sich auch Skype an die lange vor Leopards Veröffentlichung den Entwicklern bekannten Vorgaben. Hier sehe ich mir die Signatur des heruntergeladenen Programms an:

KeyWest:~ macmark$ codesign --display --verbose /Volumes/Skype/Skype.app
Executable=/Volumes/Skype/Skype.app/Contents/MacOS/Skype
Identifier=com.skype.skype
Format=bundle with Mach-O universal (i386 ppc7400)
CodeDirectory v=20001 size=59020 flags=0x0(none) hashes=2945+3 location=embedded
Signature size=3592
Signed Time=30.11.2007 10:00:39
Info.plist entries=17
Sealed Resources rules=4 files=2926


Nun möchte ich diese Signatur überprüfen:

KeyWest:~ macmark$ codesign --verify --verbose /Volumes/Skype/Skype.app
/Volumes/Skype/Skype.app: valid on disk

Das Programm wurde also nicht nachträglich verändert. Mac OS X schaut sich die Signaturen an, um Programme eindeutig wiederzuerkennen und sie gemäß der Einstellungen in Funktionen wie der "Eltern-Kontrolle", der Firewall und dem Schlüsselbund zu behandeln. Zur Zeit wird jedoch das Starten eines Programms mit ungültiger Signatur (noch) nicht vom Betriebssystem verhindert.

Wird eine Signatur als Identifizierung nicht vorgefunden und ist diese aufgrund einer der obigen Funktionen nötig, dann signiert das Security Framework das Programm.

Die automatische Aktualisierungsfunktion des Betriebssystems überprüft die digitale Signatur jedes heruntergeladenen Aktualisierungspaketes, das als seinen Ursprung Apple angibt, bevor es installiert wird. Etwaige Manipulationen durch Dritte während der Übertragung würden daher auffallen. Insbesondere ist es damit nicht möglich über die automatische Aktualisierungsfunktion einen "Bundestrojaner" einzuschleusen.

6.0.2.9 Quarantäne: Leopard contra Trojaner

Leopard kann heruntergeladene Dateien unter Quarantäne stellen: Sie werden mit Metadaten des Typs com.apple.quarantine versehen. Die Quarantäne wird sogar an Archivinhalte und Inhalte, die von Diskimages stammen, weitergegeben. Die Quarantäne sorgt dafür, daß beim Aufruf solcher Dateien geprüft wird, ob sie ausführbare Programme enthalten. Tricks, die ein heruntergeladenes Programm zum Beispiel als Musikdatei tarnen, fliegen nun auf, weil das Betriebssytem den Benutzer darüber informiert, daß es sich tatsächlich um ein ausführbares Programm handelt.

Benutzer mit entsprechenden Schreibrechten können die Quarantäne durch einmalige Bestätigung entfernen. Unter /Applications können nur Administratoren schreiben und daher nur sie installieren und nur sie die Quarantäne entfernen. Normale Benutzer können dort nicht schreiben und daher weder dort Programme installieren noch deren Quarantäne entfernen. Unter ~/Applications kann jeder Benutzer für sich schreiben, Programme installieren und deren Quarantäne entfernen.

Die Quarantäne-Markierung muß das Programm, welches die Datei herunterlädt, hinzufügen. Die Programme Safari, Mail und iChat machen das schon. Programme anderer Hersteller können dieses Verhalten auch für sich nutzen und ebenfalls die entsprechenden Metadaten an ihre Downloads hängen.

XProtect

Ab 10.6 Schnee-Leopard werden so markierte Dateien zusätzlich noch mit einer Liste relevanter Trojaner verglichen. Dabei wird jeweils mit einem Muster (Pattern) verglichen, das verschiedene Versionen des jeweiligen Trojaners erkennen kann.

Bei einem Treffer informiert das System den Anwender darüber und empfiehlt das Löschen der Datei. Ende Mai 2011 wurde ein Mechanismus eingeführt, der diese Schädlings-Erkennungs-Liste täglich aktualisiert.

Apples XProtect-Mechanismus

• sucht nicht aktiv nach Malware
• kann Malware (und auch alles andere) nicht löschen oder ändern
• ist nur ein Anhängsel für die Launch Services
• prüft ausführbare Dateien nur beim Aufruf
• informiert den User, wenn er eine bekannte Malware zu öffnen versucht
• verhindert das normale Starten von bekannter Malware
• läuft mit Userrechten

Typische AV-Software hingegen

• scannt pro-aktiv die Platte
• benötigt unter anderem auch Systemrechte
• kann beliebige Dateien löschen oder ändern
• ist eigenständig aktiv
• erhöht die Angriffsoberfläche des Rechners (siehe A Bug Hunter's Diary)

XProtect kann man daher mit AV-Software nicht in einen Topf werfen.

Unter Leopard fallen also Programme auf, die als normale Daten-Datei getarnt sind. Andere denkbare Trojanerarten würden hingegen nicht auffallen: Wenn ein Steuererklärungsprogramm noch nebenbei als "Bundestrojaner" auf der Festplatte herumspionieren würde, dann verhilft einem diese Technik nicht auf die Spur dieses Schädlings, denn wir wollten ja, daß die "Steuererklärung" ausgeführt wird. Was jedoch helfen kann, ist das Sandboxing.

6.0.2.10 Execute disable: Leopard contra Pufferüberlauf-Angriffe

Das System hat Möglichkeiten, die die feindliche Übernahme ("Entführung") von Programmen erschweren:

Eine davon ist die Nicht-Ausführbarkeit von Programm-Bereichen, die als Daten markiert sind. Ein Pufferüberlauf-Angriff, der Programmier-Fehler dieser Art auszunutzen versucht, wird dadurch schwieriger. Seit der Intel-Version von Tiger ist die Nicht-Ausführbarkeit bezogen auf den Stack möglich, welcher typischerweise Daten von Funktionen und lokale Variablen enthält. Mit Leopard geht das sowohl für 32- als auch für 64-Bit Programme. Zusätzlich kann seit Leopard der Heap von 64-Bit-Programmen vor Ausführung geschützt werden, in dem sich normalerweise statische und globale Variablen sowie dynamisch angeforderte Speicherbereiche befinden.

6.0.2.11 Library randomization: Leopard contra return to libc

Ein üblicher Weg, um execute disable zu umgehen ist, eine Rücksprungadresse auf dem Stack mit der Adresse einer bekannten Systemfunktion zu ersetzen, so daß diese ausgeführt wird. Der Trick dieser Angriffsart ist, daß die originale Rücksprungadresse auf dem Stack diesmal zwar nicht mit einer Sprungadresse zu ausführbaren Anweisungen in Datenbereichen ersetzt wird, sondern typischerweise mit der Adresse einer Systemfunktion, die legitim ausgeführt werden darf.

Um das zu erschweren, legt Leopard System-Bibliotheken an zufälligen Orten ab, so daß die Adresse schwer zu raten ist, vor allem bei 64-Bit-Adressierung, da es zu viele falsche Möglichkeiten gibt. Die Adressen ändern sich mit jeder Systemaktualisierung und sind auch auf jedem Rechner anders.

Mit 10.7 Lion gab es dann "vollständiges" ASLR und weitere Verbesserungen, wie ich in Der Löwenanteil an Sicherheit beschreibe. Allerdings ist ASLR generell nicht besonders wirksam.

6.0.2.12 Sandbox: Sandkästen in Leopard

Gelingt es einem Angreifer dennoch, ein Programm unter seine Kontrolle zu bringen, dann kann das Sandboxing den Nutzen, den ein Angreifer durch die feindliche Übernahme ("Entführung") des Programms hat, mindern.

Version 10.5 Leopard kann beliebige Programme einsperren hinsichtlich dem, was sie tun können. Dazu gehört der Dateizugriff, der Netzwerkzugriff und die Möglichkeit, andere Programme zu starten. Dabei können jeweils sehr feingliedrige Details eingestellt werden.

Die Sandkästen sind eine zusätzliche Einschränkung unabhängig von beispielsweise den POSIX-Rechten und unabhängig von ACLs. Ein Sandkasten kann, egal was man darin einstellt, nichts ermöglichen, was andere Techniken verbieten. Er ist immer nur eine weitergehende Beschränkung.

Einige Systemdienste laufen ebenfalls in solchen Sandkästen. Programme in einer Sandbox vererben diese an ihre Kind-Prozesse. Die Beschränkungen werden beim Anfordern der betreffenden Ressource beachtet. Hat der Prozeß bereits Zugriff, dann wird ihm die Ressource nicht nachträglich weggenommen. Ein Programm verwendet sandbox_init mit dem gewünschten Profil, um sich vor ungeplantem Mißbrauch zu bewahren. Es sperrt sich sozusagen selbst ein. Andersherum kann man jedoch auch beliebige Programme von außen einsperren.

Man kann zum Einsperren eines Programms von außen den Befehl sandbox-exec nutzen und eines der vorgefertigten Profile verwenden oder selbst eines erstellen. In diesem Beispiel verwende ich das Profil /usr/share/sandbox/ntpd.sb des Netzwerk-Zeitserver-Dienstes, dessen Dateizugriff auf bestimmte Dateien eingeschränkt ist, und wende es auf cat an, was Datei-Inhalte anzeigt:

KeyWest:~ macmark$ sandbox-exec -f \
/usr/share/sandbox/ntpd.sb \
cat /private/etc/smb.conf
cat: /private/etc/smb.conf: Permission denied
KeyWest:~ macmark$ sandbox-exec -f \
/usr/share/sandbox/ntpd.sb \
cat /private/etc/ntp.conf
server time.euro.apple.com

KeyWest:~ macmark$ echo 'inhalt' > neuedatei.txt
KeyWest:~ macmark$ cat neuedatei.txt
inhalt
KeyWest:~ macmark$ sandbox-exec -f \
/usr/share/sandbox/ntpd.sb \
cat neuedatei.txt
cat: neuedatei.txt: Permission denied

Selbst root hat keine Chance:

sh-3.2# whoami
root
sh-3.2# echo 'Ich bin root.' > root.txt
sh-3.2# cat root.txt
Ich bin root.
sh-3.2# sandbox-exec -f /usr/share/sandbox/ntpd.sb cat root.txt
cat: root.txt: Permission denied

Wir könnten versuchen, die Betriebssystem-Kern-Erweiterung zu entladen, die für diesen Mechanismus zuständig ist:

sh-3.2# whoami
root
sh-3.2# kextunload /System/Library/Extensions/seatbelt.kext
kextunload: unload kext /System/Library/Extensions/seatbelt.kext failed

Auch das ist nicht möglich für root.

Wie man sieht ist das Profil wirksam und das Programm kann nur noch auf ganz bestimmte Dateien zugreifen, egal unter welchem Benutzer es läuft.

So eingeschränkte Programme können, auch wenn sie feindlich übernommen wurden, diese Schranken nicht überwinden. Viele Angriffe versuchen nämlich, mit Hilfe des eroberten Prozesses und seiner Zugriffsrechte anderes zu unternehmen als wofür er vorgesehen ist. Das kann hiermit verhindert werden. Selbst Prozesse, die unter root laufen, können auf diese Weise eingeschränkt werden.

Diese Sandbox-Funktion wird unter anderem von der "Eltern-Kontrolle" und für Time Machine verwendet. So können nur Programme, die zum Thema Time Machine gehören, Dateien in den Sicherungskopien löschen. Mit zum Beispiel der Kommandozeile soll jedoch nicht einmal root diese Dateien löschen können.

6.0.2.13 Gatekeeper: Weiße Liste

Mit 10.8 Mountain Lion und 10.7.5 Lion kam die Gatekeeper-Funktion hinzu, die ein Whitelisting von heruntergeladenen mutmaßlich unschädlichen Progammen ermöglicht. Das System kann dafür sorgen, daß ein heruntergeladenes Programm nur dann ausgeführt werden kann, wenn es aus vertrauenswürdiger Quelle kommt. Apps aus Downloads werden standardmäßig nur noch ausgeführt, wenn sie von bei Apple bekannten Entwicklern kommen. Man geht davon aus, daß registrierte, identifizierbare Entwickler keine Malware schreiben.

Man kann aber auch einstellen, daß neue Programme nur ausgeführt werden, wenn sie aus Apples App Store kommen. Dann sind sie nicht nur von bekannten Entwicklern, sondern auch von Apple überprüfte Apps.

Optional kann diese Funktion auch deaktiviert werden. Und da der Gatekeeper auf der Quarantäne-Funktion aufbaut, erfaßt er zwar die meisten Downloads, aber nicht jedes Programm, das auf anderen Wegen (USB-Stick, Drive-By-Download wie bei Flashback) auf die Platte gekommen ist. Außerdem kann man als Mitglied er Admin-Gruppe per Kontextmenü Programme egal welcher Herkunft starten und Gatekeeper damit übergehen. Insgesamt sorgt Gatekeeper jedoch dafür, daß vom User aus dem Internet heruntergeladene Programme mit fragwürdiger Herkunft erstmal nicht ausgeführt werden.

Siehe auch Gatekeeper Update und Dev-Tips für Repackaging-Problem.

6.0.3 Cracker-Motivation

In Cracker-Kreisen erntet man keinen großen Respekt, indem man einen weiteren Virus für ein bekanntlich unsicheres Betriebssystem, welches viele ausnutzbare Schwachstellen aufweist aufgrund seiner Architektur und durch nicht behobene Programmierfehler, schreibt, denn das ist relativ leicht. Relativ schwierig hingegen ist es, für ein sicheres Betriebssystem den ersten relevanten Wurm zu schreiben. Ich gehe davon aus, daß einige Leute daran arbeiten, den Ruhm für den ersten Mac OS X-Wurm zu ernten. Geschafft hat es noch niemand, was für dieses Betriebssystem spricht.

Ein weiterer Anreiz ist die fehlende Konkurrenz. Wenn man Mac OS X erobern könnte, dann hätte man es für sich allein. Bei anderen Betriebssystemen bekämpfen sich die Schädlinge schon gegenseitig auf dem eroberten Rechner, um die alleinige Kontrolle zu erlangen, was nötig ist, um den Rechner voll und ganz für die eigenen bösartigen Zwecke verwenden zu können.

6.0.4 Umsorgt

Und weil Sicherheit auch ein andauernder Prozeß ist, behebt Apple gefundene Schwachstellen in der Regel schnell. Die folgende Graphik von Secunia, die dort auch eine Liste von behobenen und noch nicht behobenen Fehlern von Mac OS X anbieten, zeigt, wieviele der gefundenen Schwachstellen zur Zeit beseitigt sind:

Wenn man sich BuqTraq anschaut, dann sieht man, für welche Betriebssysteme unglaublich viele Sicherheitsprobleme sehr lange offen stehen und für welche Betriebssysteme es kaum Sicherheitsprobleme gibt, und diese auch noch schnell behoben werden.

6.0.5 Handlungsbedarf?

Um uns jedoch nicht zu sehr in Sicherheit zu wiegen, werfen wir einen Blick auf das theoretisch Machbare. Folgende Arten von Schädlingen sind möglich:

6.1 Viren Inhaltsverzeichnis

Ein Virus hängt sich an eine Datei an so wie ein Virus im wirklichen Leben sich in ein Lebewesen einnistet und dieses als Wirt benutzt. Computer-Viren bevorzugen ausführbare Dateien, also Programme als Wirt.

Ein Virus verbreitet sich passiv, indem Benutzer bereits infizierte Dateien von einem Rechner zu einem anderen Rechner transportieren. Der Transport kann beliebig erfolgen. Beispielsweise kann der Benutzer eine infizierte Datei als Anhang in eine Email einfügen oder auf Datenträgern mitnehmen. Andere Benutzer könnten die infizierte Datei auch selbst per Netzwerk auf ihren Rechner laden. Auf dem neuen Rechner angekommen, kann das Virus nun weitere Dateien befallen.

Ein Virus wird aktiv und versucht sich weiter zu verbreiten, wenn der Benutzer eine infizierte Datei öffnet oder ein infiziertes Programm startet. Die Aktivität des Virus kann sehr verschieden sein. Es könnte Dateien löschen oder den Rechner für andere Zwecke mißbrauchen.

Es ist durchaus möglich, für Mac OS X einen Virus zu schreiben. Da jedoch auf diesem System die Benutzer sehr gut untereinander getrennt sind und auch eine strenge, sichere Trennung zwischen den Benutzerbereichen und dem Betriebssystem besteht, hat ein Virus hier weniger Möglichkeiten etwas auszurichten oder sich zu verbreiten. Ein Virus wäre aus Sicht des Crackers relativ uneffektiv auf dieser Plattform und so wählt er als Zielplattform lieber eine, die ihn nicht so einengt.

6.2 Würmer Inhaltsverzeichnis

Ein Wurm ist eine spezielle Unterart eines Virus. Der erste wesentliche Unterschied ist, daß der Wurm sich aktiv selbst verbreitet ohne Zutun des Benutzers. Er repliziert sich selbst mehrfach auf dem Rechner und wandert auch über Netzwerke auf andere Rechner. Ein Wurm benötigt für seine Verbreitung entsprechende Sicherheitslücken in aktiven Netzwerkdiensten des Betriebssystems, die ihm eine vollautomatische Verbreitung technisch überhaupt erst ermöglichen. Bei den UNIX-artigen Betriebssystemen sind solche Lücken so gut wie nie anzutreffen, wodurch sie für einen Wurm nahezu unbenutzbar sind.

Mac OS X bietet extrem schlechte Randbedingungen, um einen effektiven Wurm dafür zu schreiben: Es sind standardmäßig keine Netzwerkdienste, die im Internet (WAN) erreichbar wären, aktiv. Selbst ohne aktivierte Firewall und ohne DSL-Router. Ein Wurm würde somit einfach nicht die technischen Möglichkeiten vorfinden, die ihm eine eigenständige Verbreitung anbieten. Das sehen die Autoren von Würmern offenbar genauso und sie nutzen eine andere Plattform, die ihnen die Verbreitung des Wurms erleichtert.

Ein Wurm hat es im Vergleich zum Virus aber insofern einfacher, daß er keine anderen (ausführbaren) Dateien infizieren muß, sondern eigenständig lauffähig ist. Er benötigt keinen Wirt zum Leben. Der zweite wesentliche Unterschied zum Virus ist also, daß ein Wurm autonom und nicht auf andere Programme angewiesen ist. Dieser Punkt gilt für alle Betriebssysteme.

6.3 Trojaner Inhaltsverzeichnis

Trojaner sind Programme, die vorgeben, nützlich zu sein, aber noch etwas ganz Anderes, etwas vom Benutzer Unerwünschtes tun: Das kann das Löschen von Daten sein. Das kann aber auch etwas Heimliches sein wie die Ermöglichung des Fernzugriffs auf den Rechner. Im Unterschied zu Würmern und Viren reproduzieren sich Trojaner nicht durch Infektion anderer Dateien und sie reproduzieren sich auch nicht selbständig.

Sogar ein Betriebssystem ohne Sicherheitslücken ist nicht vor Trojanern sicher, denn ein Trojaner ist immer ein Programm, was auf Befehl des Benutzers ausgeführt wird.

6.4 Rootkits Inhaltsverzeichnis

Rootkits dienen dazu, den Einbruch in ein System zu verstecken. Ein perfektes Rootkit ist nach seiner Installation auf dem Opfersystem nicht zu entdecken.

Ein Rootkit ersetzt in der Regel alle wichtigen Programme wie ls, top, ps, df, sshd und netstat bei UNIX (beziehungsweise Treiber sowie Registry-Daten im Falle von Windows) durch eigene Versionen, die den Systemadministratoren falsche Informationen liefern und den Eindruck erwecken, alles sei in Ordnung und wie gehabt mit dem System.

Um ein Rootkit zu installieren muß man die volle Kontrolle über das Opfersystem erobert haben. Das Rootkit sorgt dann dafür, daß man auch weiterhin unentdeckt der neue Herr des Systems bleibt. Ein so infiziertes System kann normalerweise nur durch Formatieren der Festplatte sicher bereinigt werden.

6.4.1 Kernel-Module

Vergleichbar mit einem Rootkit sind Kernel-Module, wenn sie bösartige Ziele verfolgen. Ein Kernel-Modul hat den Vorteil, daß es die zu versteckenden Informationen auf tieferer Ebene, auf der Systemebene, filtern kann. Ein klassisches Rootkit filtert die Informationen hingegen auf Programmebene.

Kernel-Module werden vom laufenden Betriebssystem-Kern geladen und gegebenenfalls auch wieder entladen. Sie geben dem System zusätzliche Funktionen, beispielsweise als Gerätetreiber. Ein Kernel-Module, das als Rootkit dient, fängt Datenanforderungen auf Systemebene ab und entfernt alle Daten aus der Antwort, die auf die feindliche Übernahme des Systems hindeuten.

Ein Rootkit für Mac OS X ist technisch machbar. Es könnte durch einen Virus, Wurm oder Trojaner auf den Rechner gelangen, wobei natürlich Teile des Rootkits oder das ganze Rootkit vom Schadprogramm nachgeladen werden könnten.

Nicht zu vergessen ist auch die Installation eines Rootkits durch jemanden, der direkten Zugriff auf den Rechner hat. Weitgehender Schutz vor physikalischem Zugriff kann durch die Einstellung eines Open-Firmware-Paßwortes und das Setzen der geeigneten Sicherheitsstufe erreicht werden.

6.5 Schutz Inhaltsverzeichnis

Beim Versuch, den Rechner zu schützen, kann so mancher Schuß ein Eigentor werden. Ich erläutere hier, wie nützlich die verschiedenen Maßnahmen sind und ob sie überhaupt helfen.

6.5.1 Eigentore

Bei genauerer Betrachtung von Anti-Viren-Programmen und Programmen, die dafür sorgen sollen, daß bestimmte Daten den Rechner nicht verlassen, sowie mancher Einstellungsoption in Firewalls, fällt auf, daß man zu schnell versehentlich den Bock zum Gärtner macht:

Vergleiche dazu auch die weiterführenden Artikel CSI MacMark: Nicht-Machbarkeit von Anti-Viren-Software und OS X: Antivirus-Nonsens.

6.5.1.1 Schädliche Anti-Viren-Programme

Einen wirklich wirkungsvollen Schutz durch Anti-Virenprogramme kann man nicht erwarten. Im Moment gibt es noch nichts, wovor sie Mac OS X schützen müßten. Wenn es irgendwann einen Schädling gibt, dann müssen die Anti-Virenprogramme erst aktualisiert werden, um ihn zu erkennen. Es gibt zwar auch andere Methoden, Schädlinge zu finden, welche jedoch nicht zuverlässig sind und auch gelegentlich fehlerhafterweise harmlose Programme verdächtigen.

Besonders Norton ist mit seinem Anti-Virenprogramm mehrfach negativ auf Mac OS X aufgefallen. Nortons Anti-Virenprogramm richtete auf diesem System jahrelang Schaden an und brachte dem Benutzer keinen Nutzen. Die berichteten Schäden gehen bis zum Zerstören des Betriebssystems. Harmlosere Erscheinungen waren diverse Falschmeldungen und starke Beeinträchtigung der Systemleistung. Ich beziehe mich hier auf viele glaubwürdige Berichte aus diversen Foren.

Wenn man ein Anti-Virenprogramm einsetzen möchte, dann sollte man zu einem greifen, das wirklich nur Viren und nicht das Betriebssystem bekämpft.

Anti-Viren-Programme stellen, da sie unter hohen Rechten laufen müssen, um effektiv arbeiten zu können, selbst ein Sicherheitsproblem dar. Sie sind gerne selbst das Ziel einer Attacke, meistens sogar ermöglicht aufgrund eigener Programmierfehler. Einige sind sogar dafür bekannt, ein gesundes System zu zerschiessen.

Auch bekannte Mac-Hacker sehen keinen Nutzen in Anti-Virenprogrammen für Mac OS X.

6.5.1.2 Schädliche Daten-Schutz-Programme

Mit anderen Schutzprogrammen ist es nicht besser: Programme, die Daten geheim halten sollen, lassen sich austricksen, so daß man sogar schneller an die Daten kommt. Solche Programme sollen dazu dienen, daß bestimmte Daten nicht ins Netz geschickt werden. Sie unterbinden jeden Versuch, dies zu tun. Der geschickte Angreifer erkennt die gesuchten Daten jedoch dann daran, welche nicht geschickt werden können. Das wird beispielsweise bei Geheimnummern gerne verwendet: Man probiert alle möglichen Nummern zu schicken und die, die nicht funktioniert, ist die richtige.

6.5.1.3 Schädliche Firewall-Einstellungen

Hauptsächlich dient eine Firewall dazu, dafür zu sorgen, daß Dienste des Rechners nicht über das Netz benutzt werden können. Das setzt jedoch voraus, daß überhaupt Netzwerkdienste angeboten werden, die geblockt werden könnten.

Es ergibt keinen Sinn, einen Netzwerkdienst zu starten und diesen dann mit der Firewall zu blocken. Sinnvoll ist nur, diesen Netzwerkdienst nicht laufen zu lassen, denn ein Dienst für das Netz, der nicht im Netz erreichbar ist, ist widersinnig.

Mac OS X 10.5 Leopard hat zwei Firewalls, die auf unterschiedlichen Protokollebenen arbeiten: Die bei Leopard neu hinzugekommene, die auf Programmebene den Netzverkehr regeln kann, und die schon bei Tiger und älteren Versionen verfügbare ipfw, die auf der tieferen Paketebene den Netzwerkverkehr kontrollieren kann. Beide Firewalls können gleichzeitig betrieben werden und ermöglichen zusammen eine umfassende Regelung. Dabei hat ipfw Vorrang und die Application Level Firewall ist aufgrund der Protokollebenen nachgeordnet.

Die Anwendungs-Firewall soll dem normalen Benutzer, dem Portnummern nichts sagen, eine Möglichkeit geben, überhaupt Einstellungen machen und verstehen zu können. Eine Filterung von Ports würde auch nicht immer nützen, da einige Programme ihre Ports wechseln.

Ein vom Rechner angebotener Dienst steht nur dann im Internet zur Verfügung, wenn der DSL-Router den entsprechenden Port an den Rechner weiterleitet. Standardmäßig wird nichts weitergeleitet. Ohne Router steht jeder Dienst des Rechners auch im Internet zur Verfügung.

Bei Windows ist das Problem, daß es und seine Programme viel zu viel RPC (Remote Procedure Calls) auch für Nicht-Netz-Programme einsetzen; dort also ziemlich viele Dienste laufen, die auch unnötigerweise dem Netz zur Verfügung stehen. Um diesen Architektur-Fehler auszugleichen, sperrt man die entsprechenden Ports mit einer Firewall.

Bei Mac OS X laufen kaum Netzwerkdienste, wenn man sie nicht einschaltet (unter dem Kontrollfeld Sharing) und dann auch nur ein paar. Mac OS X und andere UNIX-Betriebssysteme nutzen nicht wie Windows übermäßig RPC in Nicht-Netz-Programmen, wodurch auch nicht Unmengen an Diensten angeboten werden, die durch eine Firewall wieder eingesperrt werden müßten. Insbesondere weisen bei Mac OS X normale Nicht-Netz-Programme keine Netzwerkdienste auf; sie sind auch ohne Firewall nicht von außen zu erreichen.

Es ist bei Mac OS X und anderen UNIX-Betriebssystemen nicht so wie bei Windows, daß eine Unmenge an Diensten laufen, von denen man nichts ahnt und die zudem von Nicht-Netz-Programmen angeboten werden.

Normalerweise bietet also eine Firewall auf dem zu schützenden Rechner keinen nennenswerten zusätzlichen Schutz. Sie kann im Gegenteil selbst verlockendes Ziel eines Angriffs sein, da sie die vom Angreifer gerne eroberten höheren Rechte hat und zudem mit beliebigem Netzverkehr erreichbar ist.

Siehe auch OS X: Firewall-Nonsens.

6.5.1.4 Schädlicher Tarnmodus

Der sogenannte Tarnmodus (stealth mode) nützt nicht wirklich etwas, sondern behindert den Rechner, weil er dann nicht mehr dem Internetstandard entspricht.

Wenn der Rechner tatsächlich nicht da wäre, würde die letzte Station vor dem Rechner an den anfragenden Rechner melden, daß das Ziel nicht erreichbar ist. Im Tarnmodus kommt jedoch keine Nachricht zurück. Wenn der Rechner internetkonform eingestellt wäre, dann würde er selbst eine Antwort schicken. Also kann man aus der Tatsache, daß keine Antwort zurückkommt, schlußfolgern, daß der Rechner da ist, aber nicht antwortet. Ein Rechner kann sich im Internet nicht selbst verstecken. Das kann nur ein Router vor ihm für ihn tun.

Ein Angreifer würde sich durch so eine alberne Augenwischerei weder in die Irre führen noch sich abhalten lassen. Der sogenannte Ping ist beispielsweise eine der ICMP-Nachrichten, die durch den Tarnmodus nicht mehr funktionieren. So haben Microsoft und eBay den Tarnmodus aktiv: Ein Ping bekommt keine Antwort von ihnen. Sind die beiden tot? Keineswegs, denn wir erreichen sie ja noch per Webbrowser. Also kann man nicht einmal einen Laien durch den Tarnmodus beirren.

6.5.2 Fazit zu Schutzmaßnahmen

Momentan bieten Schutzprogramme auf Mac OS X mehr Schaden als Nutzen. Und wenn man keine Schadprogramme weiterleiten möchte, dann sollte man keine Anhänge weiterleiten, die auf einem anderen Betriebssystem erstellt wurden.

Ein Schutz vor Trojanern ist, wenn man nur solche Dateien und Programme benutzt, bei denen man sicher ist, daß sie sauber sind. Oder anders formuliert: Man sollte nichts doppelklicken, was man nicht kennt. Selbst Nachrichten von Freunden können durch einen Wurm auf ihrem Rechner verschickt worden sein und man sollte nur solchen Anhängen trauen, die man selbst angefordert hat.

6.6 Panik und Helden Inhaltsverzeichnis

Jeder kennt sicher die Berichte von Feuerwehrleuten, die selbst Feuer gelegt haben, um dann als heldenhafter Retter aufzutreten. In ähnlicher Weise versuchen auch im Mac OS X-Bereich diverse Leute zu zweifelhaftem Ruhm zu kommen: Sie finden eine kleines Sicherheitsproblem in Mac OS X, welches allerdings keine praktisch wirklich effizient nutzbare Angriffsmöglichkeit darstellt. Meistens handelt es sich um Konzepte für Trojaner, was aber die Sache absurd macht, denn ein Trojaner benötigt nie eine Sicherheitslücke, um zu funktionieren, wie oben dargelegt.

So wurden uns schon Trojaner als Wurmkonzepte verkauft, was nicht nur technisch falsch, sondern auch absolut verantwortungslos und unzulässig übertrieben ist. Die falsche Bezeichnung wird immer gerne wieder genutzt, um mehr Aufsehen zu erregen. So gab es in den letzten Jahren schon diverse Male "den ersten Wurm" für Mac OS X. Keiner hat jedoch gehalten, was die Schlagzeile versprochen hatte. Denn wenn es nur ein Trojaner ist, dann verbreitet es sich nicht von allein, sondern muß den Benutzer zum Starten des fremden Programms verleiten und um effizient zu sein, auch noch um die Eingabe eines Administrator-Kennwortes bitten und dieses erhalten. Und das ist ein riesiger Unterschied zu einer vollautomatischen Verbreitung und der ebenso vollautomatischen Anrichtung von Schaden.

Ein Trojaner ist ein billiges Konzept: Man gibt beispielsweise vor, die Lottozahlen mit seinem Programm erzeugen zu können und löscht stattdessen die Daten im Verzeichnis des Benutzers oder verschickt sie in's Internet. Mehr kann ein Trojaner ohne weiteres auf dieser Plattform nicht anrichten. Ein Trojaner verläßt sich voll und ganz auf die Gutgläubigkeit des Benutzers.

6.7 Dashboard-Lücke geschlossen Inhaltsverzeichnis

In 10.4 gibt es das Dashboard, was kleine Programme beherbergt, die sogenannten Widgets. Es hat ein Sicherheitsmodell, das wie folgt funktioniert: Einem neuen Widget wird jede potentiell gefährliche Aktion verwehrt, wenn es sie nicht schriftlich beantragt hat. Das heißt, ein Widget kann nur dann eine potentiell gefährliche Aktion durchführen, wenn sie in seiner Informationsliste eingetragen ist. Enthält diese Liste nun einen riskanten Eintrag, dann wird der Benutzer vor dem ersten Start, der das Widget installieren würde, gefragt, ob er das will. Wenn das Widget dann installiert ist, wird nicht mehr erneut gefragt. Das Widget befindet sich dann in einem Unterverzeichnis des Benutzers.

Als potentiell gefährlich und genehmigungspflichtig werden solche Aktionen eingestuft:

• Zugriff auf Dateien, die nicht im Widget enthalten sind.
• Nutzung eines Web Kit oder standardmäßigem Browser Plug-Ins.
• Netzwerkzugriff.
• Starten eines Java Applets.
• Starten eines Kommandozeilen-Programms.
• Nutzung eines Widget Plug-Ins.

Fehler in 10.4.0

Es gibt allerdings den Hinweis, daß dieser Sicherheitsmechnismus, dem die Widgets unterliegen, mit einem Trick umgangen werden kann: Eine Webseite, die einen speziellen unüblichen HTML-Befehl zum Herunterladen eines potentiell gefährlichen Widgets nutzt, sorgt für die vollautomatische Installation des Widgets, wenn man in Safari die Option "Sichere Dateien nach dem Herunterladen öffnen" nicht deaktiviert hat. Allerdings wird das Widget nicht automatisch gestartet. Zum Starten muß der Benutzer es erst noch im Dashboard aus der Liste passiver Widgets heraus aktivieren. Offensichtlich funktioniert an dieser Stelle der Sicherheits-Mechanismus für Widgets nicht so, wie er geplant ist, denn dem Benutzer wird nicht die oben besprochene warnende Meldung gezeigt. Daher ist dringend geraten, die genannte Option in Safari abzuschalten, bis Apple, die bereits informiert sind über die Details, diesen Fehler behebt.

6.7.2 Fehler in 10.4.1 behoben

Die Version 10.4.1 hat diesen Fehler nicht mehr. Nun wird der Benutzer gefragt, ob er das Programm (das Widget) wirklich herunterladen will, selbst wenn die Internetseite versucht, es heimlich herunterzuladen auf den Rechner und auch wenn automatisches Öffnen von sicheren Dateien in Safari aktiviert ist. Man sollte die Option in Safari trotzdem besser nicht aktiviert haben.

6.8 InputManager auf Leopard

InputManager sind für Eingabeerleichterungen und Internationalisierung konzipiert worden. In der Praxis wurden sie allerdings für allgemeine Plugins mißbraucht, um Programme zur Laufzeit zu verändern.

Ein InputManager läuft auf Leopard nur noch, wenn er folgende Bedingungen erfüllt:

• Er muß in /Library/InputManagers/ liegen.
• Alle Dateien in diesem Verzeichnis und das Verzeichnis selbst müssen root und der Admin-Gruppe gehören. Dateien im InputManager dürfen nur für root schreibbar sein.
• Prozesse, die unter root oder dessen Gruppe wheel laufen, laden keine InputManager.
• Der Prozeß muß sich in der gerade aktiven Workspace-Session (im gerade aktiven virtuellen Schreibtisch) befinden, wenn er InputManager lädt.
• Der Benutzer und die Gruppe des Prozesses dürfen nicht durch setguid verändert sein.
• 64-Bit-Prozesse können keine InputManager laden.

Ein unbemerktes Einschleusen ist daher also nicht mehr möglich und wichtige Prozesse sind immun.

Das automatische Laden der InputManager ist nun offiziell nicht mehr unterstützt und wird in Zukunft wahrscheinlich ganz deaktiviert.

6.9 Thematisch ergänzende Querverweise

• Kapitel 0.16 OS X: Firewall-Nonsens
• Kapitel 0.17 OS X: Antivirus-Nonsens – nutzlos und gefährlich
• Kapitel 0.14 CSI MacMark: Nicht-Machbarkeit von Anti-Viren-Software
• Kapitel 0.10 Untersuchung verfügbarer Mac OS X Viren und Machbarkeits-Analyse. Sind Viren möglich und was sind die Bedingungen dafür?
• Kapitel 0.11: OS X - Security orthodox. Eine Beurteilung von heises "Security paradox"-Artikeln in c't, Mac&i und auf heise.de.
• Kapitel 0.3: Einordnung von mach_override und mach_inject. Warum ein Angreifer davon nichts hat. Dieses Thema wird gerne und oft unvollständig betrachtet, um es fälschlicherweise als Sicherheitsrisiko darstellen zu können.
• Kapitel 0.9 UAC, das Sicherheits-Plazebo.
• Kapitel 8.3: SSH-Tunnel und Sicherheit. Nutzung von Tunneln und Einschränkungen bezüglich möglicher Benutzer.
• daily.out: Sicherheits-Lücken zählen wie Pippi Langstrumpf
• daily.out: Ausführbarkeit des Heap
• daily.out: Root-Shell einsperren
• daily.out: Safari einsperren
• daily.out: Google Chrome: Sandbox-Mechanismus von OS X rockt
• daily.out: Unvollendet: The Month of Apple Bugs
• daily.out: MacBook nicht gehackt in zwei Minuten
• daily.out: MacBook wieder nicht gehackt in zwei Minuten
• daily.out: Pwn2Own: Prüfung der Nachrichten 2010
• daily.out: Pwn2Own Vorhersage
• daily.out: Windows 7: Weiße Liste ermöglicht stille Rechte-Erhöhung für Schadprogramme
• daily.out: Gedanken zur Samba-Lücke (aktualisiert 2010-02-09)
• daily.out: Sieben Monate nutzlose Exploits
• daily.out: Pwn2Own, der Fake-Wettbewerb
• daily.out: Klartext-Paßworte im RAM
• daily.out: MacDefender, drei Monate später
• daily.out: Unter Geiern
• daily.out: Der Löwenanteil an Sicherheit
• daily.out: Im Parallel-Universum der Computer-Sicherheit
• daily.out: Anti Anti-Virus
• daily.out: Java Out-Of-Process
• daily.out: ASLR und DEP sind nahezu wertlos, wörtlich
• daily.out: MacDefender, das Nachspiel
• daily.out: Macintosh-Weltuntergang
• daily.out: Trojaner-Baukasten Weyland-Yutani

---