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

Stichwort-Liste

6.0 Einleitung

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

Die Korrektheit eines Programms kann nur bis zu einer bestimmten Anzahl Zeilen bewiesen werden.

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

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.

Eine wirkungsvolle Schwachstelle ist eine, mit deren Hilfe ein Fremder ohne Zutun der Benutzer den Rechner in Standardkonfiguration per Netzwerk übernehmen 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:

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.

Mac installierte Basis

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.

Eine der besten Analysen des Witty-Wurms ist der Artikel von Nicholas Weaver und Dan Ellis: Reflections on Witty: Analyzing the Attacker.

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).

Verbreitung von iOS und Android in 2010

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?

Wer wie ich mit Microsoft direkt jahrelang zu tun hatte, der kennt den wahren Grund für die Verbreitung und die Anfälligkeit von Windows. Es ist die schlichte Offenheit des Systems hinsichtlich des Angebotes an Schnittstellen für Dritte (Programmiersprachen, einfache Zugriffe auf die Systemebenen usw.). Das half der Verbreitung von Windows. Es half aber auch, Windows so anfällig zu machen wie kein anderes System. Wer alle Türen offen hält, bekommt eben auch ungebetene Gäste zu Besuch.

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.

NT war ursprünglich nicht richtig mehrbenutzerfähig

Multi-User ist definiert durch gleichzeitige Nutzung, sogenannte "concurrent sessions".

Daß jedes Microsoft-System vor NT in keiner Weise mehrbenutzerfähig war, dürfte allgemein bekannt sein. Aber selbst NT hatte einen langen Weg vor sich: Microsoft hat Windows NT erst 1998 durch eine Erweiterung von Version 4 mehrbenutzerfähig im Netzwerk gemacht: Microsoft makes Windows NT multi-user at last. Und die iX hat im November 1998 geschrieben, es wäre das erste Multiuser-fähige NT nun aus Herstellerhand.

Der Weg zum Mehrbenutzersystem erwies sich als Hürdenlauf: So funktioniert der schnelle Benutzerwechsel von XP nicht, wenn der Rechner Mitglied einer Netzwerk-Domäne ist. Microsoft ging offenbar davon aus, daß nur ein User pro Computer angemeldet ist, wenn der Rechner im Netzwerk ist.

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.

Datei-Trennung und Microsoft

Eine Datei-Trennung unter Windows gab es anfangs überhaupt nicht und mit Vista immer noch nicht sauber, wodurch es Schadprogrammen erleichtet wird, sich zu verbreiten und Schaden zu verursachen:

Viren lieben FAT

Bei den Betriebssystemen von Microsoft war FAT seit 1976/77 über 20 Jahre (und wohl auch heute noch) das am meisten eingesetzte Dateisystem. FAT kann keine Dateien zwischen Benutzern trennen. Jedes Programm kann bei FAT jede Datei auf der ganzen Festplatte beschreiben. FAT kennt keine Dateibesitzer. Ein Virus findet auf FAT keine Hindernisse vor und kann alles nach Belieben infizieren. Microsoft hat mit Jahrzehnten FAT den Virenautoren die gesamte Festplatte sozusagen geschenkt und hat sich die Generationen von Virenschreibern damit selbst herangezüchtet.

Ein Sicherheitsmodell, wie es von UNIX-Dateisystemen bekannt ist, bieten die Dateisysteme unter Windows nicht. Bei FAT gibt es keine Dateizugriffsrechte, was dazu führt, daß keiner und jeder der Besitzer ist, sprich vollen Zugriff auf alles hat.

Mit FAT gehörte also jedem Benutzer und auch jedem Virus die ganze Platte. Das wurde erst mit NTFS behoben, was lange brauchte, bis es breit eingesetzt wurde. Beim NTFS gibt es allerdings ebenfalls keine dem UNIX-Modell entsprechenden Datei-Besitzer oder Zugriffssteuerung, aber mit Hilfe von ACLs konnte das trotzdem umgesetzt werden.

Dies ist einer der Punkte, an denen man sieht, daß Windows nicht als Mehrbenutzer-Betriebssystem geplant war.

Windows NT ACLs unsicher

Die ACL-Umsetzung, die mit Windows NT eingeführt wurde, war allerdings unsicher: Um abwärtskompatibel zu bleiben, erlaubt das Betriebssystem, diese zu ignorieren.

Administrator gleichmächtig mit System

Wenn man sich unter Vista die einzelnen Dateirechte im Systemverzeichnis ansieht, dann haben "SYSTEM" und die Administrator-Gruppe jeweils identische Rechte. In einigen Fällen jedoch hat der "TrustedInstaller" mehr Rechte. Das kann aber ein Administrator ohne Probleme ändern, indem er den Besitz der Datei übernimmt und die Zugriffsrechte anpaßt und falls nötig auf "ok" und "fortfahren" klickt.

Nicht private "Private Verzeichnisse"

Unter Vista hat jeder Administrator Zugriff auf die privaten Verzeichnisse der anderen Benutzer.

Standardmäßig kein Paßwort

Wenn man unter Vista einen Benutzer anlegt, dann gibt es kein Eingabefeld für die Festlegung eines Paßwortes. Jeder Benutzer, auch die (trotz UAC) allmächtigen Vista-Administratoren, sind erst einmal ohne Paßwort.

Es gibt beim Anlegen keinen Hinweis darauf, dem Konto doch bitte ein Paßwort zur Sicherheit zu geben, damit sich nicht jeder anmelden kann darunter, was insbesondere für Administrator-Konten die volle Kontrolle ermöglicht. Daß dies für Vista der Normalzustand ist, sieht man auch daran, daß in der Benutzerliste Konten, die ein Paßwort besitzen, zusätzlich "kennwortgeschützt" unter ihrem Namen stehen haben.

Will man unter Vista das Benutzerkonto absichern, dann muß man, nachdem das Konto angelegt wurde, diesem nachträglich ein Paßwort geben. Dazu ist eine gesonderte Funktion extra aufzurufen.

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.

Beispiel: Der Mac OS X Aktivitätsmonitor, der alle Prozesse graphisch darstellt, läuft unter dem Benutzer, der ihn aufruft. Seine Daten bekommt der Aktivitätsmonitor jedoch vom pmTool, welches unter root ausgeführt wird, um mehr als nur Informationen über die eigenen Prozesse zu erhalten. Dieses ist ein separates kleines Hintergrund-Programm, das mit im Programmpaket des Aktivitätsmonitors liegt.

Seit Schnee-Leopard ist das pmTool vom activitymonitord abgelöst worden. Dieser Dämon ist ein direktes Kind des System-Prozesses launchd und kein Kindprozeß des als Benutzer-Prozeß laufenden Aktivitätsmonitors. Das ist wichtig, um eine ungewollte Rechteausweitung zu verhindern, weil der Mutterprozeß in der Regel seine Kindprozesse manipulieren kann.

Wie man an Bild 13 und der umgebenden Beschreibung sehen kann, führte Vista eine neue Funktion ein, die es ermöglicht, einen Systemprozeß als Kind an einen unprivilegierten Benutzerprozeß umzuhängen. Das ist aus oben genannten Grund keine gute Idee. Vista machte hier einen Sicherheitsschritt rückwärts, Schnee-Leopard vorwärts.

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.

Im privaten Bereich und in Firmen habe ich bisher alle, die Windows verwenden, als Administrator arbeiten sehen. Mit Vista bestärkt Microsoft den Benutzer noch darin, als solch ein Administrator zu arbeiten und läßt ihn im schlimmsten Fall auf OK klicken, was keine Authentifizierung ist.

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:

So sollte man Betriebssystem-Architektur nicht machen: Architektur-Fehler von Windows .

Architekturfehler in Windows, die Mac OS X nicht macht: Five Architectural Flaws in Windows Solved In Mac OS X

Nachrüsten auf ungeeigneter Grundlage hilft nicht. Heise Security: Windows: Flickschusterei bei Benutzerrechten

Sicherheitsabfragen in Vista ausgehebelt. Heise Security: Vistas User Account Control wenig vertrauenswürdig

Sicherheitsmodell von Vista ist nicht ernst gemeint. Heise Security: Microsoft relativiert Vista-Sicherheitsfunktionen

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.

Weil Windows und seine Programme jedoch auf Remote Procedure Calls angewiesen sind, kann man dies nicht abschalten: Es würde vieles nicht mehr funktionieren, was man braucht.

Darum wird mit Hilfe einer Firewall diesem Architekturfehler entgegengewirkt: Die angebotenen Netzwerkzugriffe, die eigentlich sowieso unnötig sind, werden durch Firewall-Regeln eingeschränkt.

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.

Vergleiche zu den folgenden Absätzen das dritte Kapitel aus The Art of UNIX Programming.

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.

Wie Microsoft selbst dokumentiert:

NT 3.5.1 war schon ziemlich monolithisch, weil es viele Dienste im Kernel laufen hat:

"From its earliest days Windows NT has implemented its memory manager, integrated cache manager, file systems (including network redirectors), object/security manager, network protocols, network server, and all thread/process management as kernel-mode subsystems while retaining a highly modular design."

Eine Mikrokernel-Architektur hingegen hat beispielsweise Dateisysteme im Userspace, aber das schreibt Mircosoft auch selbst (Hervorhebungen von mir):

"In a pure microkernel operating system the file system implementation is run in user mode, so theoretically it can't crash the entire operating system."

NT 4.0 wurde noch monolithischer, weil es weitere Dienste, unter anderem die GUI, auch noch in den Kernel verlegte:

"… because the graphics and windowing subsystems have a very high rate of interaction with hardware …, the Windows NT 4.0 design team decided to move that common functionality from user mode into kernel mode. … With this new release, the Window Manager, GDI, and related graphics device drivers have been moved to the Windows NT Executive running in kernel mode. … In the current change, a set of services previously implemented in user mode are now operating in kernel mode."

Und sie haben sogar vorausgeahnt, was später passieren würde: Bugs in der GUI (!) gefährden ab NT 4.0 den Kernel und damit das gesamte System:

"One of the side effects of this change is that now Window Manager, GDI, and graphics drivers have the potential to write directly to other spaces within the Executive, and thereby possibly disrupting the stability of the whole system."

Und damit haben sie die Architektur der Performance geopfert:

"So what does moving Window Manager and GDI from their place as user-mode subsystems to kernel-mode Executive services really mean to the user? To the administrator? To the systems developer? Simply put, the move delivers improved performance and increased functionality with a decrease in memory requirements!"

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.)

Dies ist ein weiterer Punkt, an dem man sieht, daß Windows nicht als Mehrbenutzer-Betriebssystem geplant war.

Vergleiche dazu, was Microsoft diesbezüglich in dem Absatz Preventing Application-Based Shatter Attacks schreibt:

"… Shatter attacks take over a user interface by using the Windows messaging system (how applications communicate with the Windows operating system and each other) to run malicious code or overwrite administrative processes. The primary cause of this problem is that any application can send a message to any other application on the same desktop. When the target application receives a message, it has no way of discerning the process source or determining whether the application sending the message is authorized to do so. …"

Bei Windows Vista wird das Risiko, daß Angriffe, die diese Eigenschaft von Windows ausnutzen, erfolgreich sind, vermindert, aber auf Kosten der Anwendungskommunikation.

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.

Vergleiche dazu den Abschnitt "User Interface Privilege Isolation and some little Fun" in Running Vista Every Day! von Joanna Rutkowska, in dem sie beschreibt, wie man die Sicherheits-Stufen in Windows Vista umgeht und seine Rechte eskaliert.

Vergleiche außerdem "Vista Security Model – A Big Joke?", in dem Joanna Rutkowska sich darüber wundert, daß Microsoft selbst die neuen Sicherheitsfunktionen in Windows Vista gar nicht mehr als Sicherheitsfunktionen ansieht.

Vergleiche auch UAC, das Sicherheits-Plazebo.

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.

Microsoft zieht sich übrigens seit Bekanntwerden dieses Architekturfehlers im Jahre 2002 mit der Bemerkung aus der Affäre, daß solche Angriffsmöglichkeiten "die Microsoft-Definition eines Sicherheitsproblems nicht erfüllen".

Das Problem ist, daß man Architekturfehler nur durch einen Architekturwechsel beheben kann und nicht durch zusätzliche Flicken (in Gestalt von UAC und UIPI). Was können sie also tun? Es durch neues und anderes Betriebssystem ersetzen. Apple hat das ja schon vorgemacht mit dem Wechsel von 9 zu X.

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.

Vergleiche dazu bei Microsoft: Dynamic-Link Library Search Order

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

Internet Explorer 7 - Still Spyware Writers Heaven

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 Mac OS X sind installationsrelevante Verzeichnisse folgendermaßen getrennt:

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.

Anstatt eine saubere Trennung der Bibliotheken wie unter Mac OS X durchzusetzen, festigt Vista die Unart, daß jede Installation ins System schreiben darf.

Es ist weiterhin erlaubt und es wird der Installation auch als Erfolg zurückgemeldet, aber tatsächlich wird der Schreibversuch heimlich in virtuelle Vereichnisse umgelenkt. Vista belügt einfach die Installation: "… compatibility is hugely important, so we took another compatibility approach: we just lie …". Eine saubere Architektur ist etwas anderes.

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.

WinFS sollte ursprünglich mit Vista kommen, wurde jedoch auf später verschoben:

… WinFS is not a feature that will come with the Longhorn Operating System. However, WinFS will be available on the Windows platform at some future date …

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

Vergleiche dazu: The Register: Windows Depends Too Heavily on the RPC model

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.

DARPA hatte das TCP/IP-Protokoll entwickelt und beauftragte die Universität von Berkeley, Kalifornien, damit, es auf BSD UNIX zu implementieren. ARPANET stellte 1983 auf TCP/IP um und im selben Jahr veröffentlichte Berkeley die erste Version von UNIX mit eingebautem TCP/IP. Die gesamte Informatik-Forschung benutzte BSD UNIX und das Netzwerk expandierte wie ein Lauffeuer. Die Integration von TCP/IP in UNIX und seine Nutzung als Entwicklungs-Basis waren die beiden Schlüsselfaktoren für das schnelle Wachstum des Internets (und von UNIX).

Die Referenz-Implementierung von TCP/IP wurde 1983 in BSD UNIX vorgenommen. Seither waren UNIX und TCP/IP miteinander verheiratet. Sämtliche Rechner des Internets waren zu Beginn und lange danach ausschließlich UNIX-Rechner.

Andere wichtige Internetprotokolle sind ebenfalls auf UNIX entstanden: UUCP für Emails und das USENET für News beispielsweise.

Die IETF wurde erst Jahre danach 1986 gegründet.

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.

Es kommt nicht auf die Menge (Quantität), sondern auf die Qualität (Schwere) der Fehler an. Die meisten Studien zählen einfach nur die Fehleranzahl. Diese ist jedoch für die Sicherheit unbedeutend, denn es genügt ein einziger großer Fehler, um tausende kleine in den Schatten zu stellen, weil mit dem einen Fehler mehr Schaden angerichtet werden kann als mit allen anderen zusammen.

Typische Vertreter dafür sind die RPC-Würmer bei Windows. So stellte allein schon der 2008er Bug, der den Conficker-Wurm auf Windows ermöglichte, eine größere Gefahr dar als alle Fehler von OS X aus den acht Jahren davor zusammen: Systemübernahme per Netz (Internet) ohne Zutun der Benutzer.

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.

Vergleiche zu diesen Absätzen im Buch TCP/IP von Thomas Zwolsky das Kapitel 9 bezüglich Sicherheit.

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.

Vergleiche dazu in dem Buch Mac OS X Internals von Amit Singh das Kapitel 2.14. Security.

Genaue Ausführungen zu allen Abschnitten hier finden sich unter Authorization Concepts von Apple.

Bezüglich Sicherheitsabfragen siehe auch Security Server Daemon von Apple.

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.

Apple: Code Signing Guide: Digital Signatures and Signed Code

Apple: Code Signing Release Notes for Mac OS X v10.5

Apple: Mac OS X Leopard Security

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.

Warnung: Keine Musikdatei, sondern Programm!

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.

Nach meinen Experimenten werden sogar heruntergeladene Dateien der Programme, die in der /System/Library/CoreServices/\
CoreTypes.bundle/Contents/Resources/Exceptions.plist
-Datei gelistet sind, vom System mit dem Quarantäne-Attribut belegt. Das betrifft sogar eine Programmversion von OmniWeb auf meiner Platte, die mehrere Jahre älter als Leopard ist.

Offenbar werden also auch die Downloads von diversen Programmen abgesichert, die diese neue Quarantäne-Funktion nicht selbständig nutzen.

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.

Die Muster sind in der Datei /System/Library/CoreServices/\
CoreTypes.bundle/Contents/Resources/XProtect.plist
definiert. Mit meiner WallsOfTroy.app kann man die eingebaute Schädlingsliste ansehen. Ab 10.9 Mavericks hat sich der Ort geändert.

Die bei Apple angefragte URL für die Muster war bei meinem letzten Test für Mountain Lion diese, für Lion diese und für Snow-Leopard diese. Die periodischen Anfragen sind in /System/Library/LaunchDaemons/com.apple.xprotectupdater.plist konfiguriert und verwenden das Programm /usr/libexec/XProtectUpdater.

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.

Im Mac App Store: Meine WallsOfTroy.app für OS X zur Anzeige der eingebauten XProtect-Schädlingsliste und der geblockten Internet-Plugin-Versionen und der jeweils installierten Version.

Apples XProtect-Mechanismus

Typische AV-Software hingegen

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

Leopard kennt den speziellen Befehl xattr zur Handhabung von erweiterten Attributen (extended attributes), von denen die Quarantäne eines ist. Siehe 8.5.1 Erweiterte Attribute von Dateien im Terminalkapitel.

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.

Wenn ein Programm ein Flugzeug wäre, dann würde Sandboxing dafür sorgen, daß das Flugzeug nur auf festgelegten Flugplätzen landet, auch wenn es entführt wurde.

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.

Sandboxing basiert wie einige andere neue Sicherheits-Eigenschaften von Leopard auf dem Mandatory Access Control-Mechanismus, der den Zugriff auf System-Ressourcen (Netzwerke, Dateisysteme und Prozeßausführung) eingrenzt.

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.

Windows Vista hat keinen Mechanismus, der mit Leopards Sandbox-Funktionen vergleichbar wäre, auch wenn einiges auf den ersten Blick irgendwie ähnlich klingt.

Microsoft schreibt selbst: "Der Integritäts-Mechanismus von Windows Vista kann keine vollständige Isolations-Barriere zur Verfügung stellen. Der Windows-Integritäts-Mechanismus ist nicht als Anwendungs-Sandbox gedacht."

Die Integritätsstufen in Windows Vista bieten nicht annähernd die Möglichkeiten und Einschränkungen, die man unter Leopard nutzen kann. Unter Leopard kann die jeweilige Sandbox beliebig detailliert sein und das, was ein Programm tun kann, bis in das allerkleinste Detail regeln, während Windows Vista die Objekte nur auf Stufen verteilt, wobei innerhalb einer Stufe keine Einschränkungen bestehen und Systemprozesse kompromittierte Daten aus unteren Stufen lesen können.

Leider können diese Integritätsstufen von Windows Vista selbst das vergleichsweise Wenige nicht halten, was sie in der Theorie versprechen (siehe Windows-Architekturfehler, Punkt 3 und Shatter-Attacks auf Windows Vista).

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:

Mac OS X Patch-Status

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.

The Register: Linux vs. Windows Viruses

c't: Eine sichere Burg

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.

Ich gebrauche "Trojaner" als Abkürzung für "trojanisches Pferd". Es geht auf die berühmte Sage vom trojanischen Krieg zurück:

Als die Griechen lange vergeblich versucht hatten, die Stadt Troja zu erobern, griffen sie zu einer List, denn die Stadtmauern Trojas waren zu hoch und zu stark, um von ihrer Armee überwunden zu werden. Sie bauten ein großes hölzernes Pferd und ließen es als Geschenk vor der Stadt zurück. Die Trojaner, glücklich über das scheinbare Kriegsende, öffneten das Stadttor und holten das Pferd hinein. Das Pferd war jedoch innen hohl und in ihm waren einige Griechen versteckt.

Nachts, als alles schlief, verließen die Griechen das Holzpferd und öffneten Trojas Stadttor von innen. Die griechische Armee stürmte nun rasch durch das offene Tor ins Innere von Troja. Troja wurde in Schutt und Asche gelegt.

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.

Umfangreiche Darlegungen zu diesen Themen finden sich in dem Buch Maximum Protection von Ryan Russel, zweite Auflage.

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.

Open-Firmware-Paßwort und Sicherheitsstufen

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.

MacFixIt schreibt: Mac OS X anti-virus software: More trouble than it's worth? Dort werden unter anderem die Schäden aufgeführt, die die verschiedenen Antiviren-Programme angerichtet haben.

Apple-Foren: Antiviren-Software friert den Rechner ein.

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.

Man kann Dateien selbst untersuchen, ohne sie doppelzuklicken.

Einige Monate nach mir hat es auch heise bemerkt: Zu viele Rechte bei Antivirensoftware.

Noch ein Artikel auf heise dazu: Antiviren-Software als Einfallstor.

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.

In Leopard ist die ipfw mindestens für den "Tarnmodus" zuständig. Der entsprechende Haken in den Systemeinstellungen ergänzt beziehungsweise entfernt die Regel 33300 0 0 deny icmp from any to me in icmptypes 8.

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.

Ein Widget wird unter dem Benutzer ausgeführt, der es startet. Es kann prinzipiell alles, was ein normales Programm kann, und ist daher als Trojaner geeignet. Besonders deswegen, weil viele Benutzer Widgets nicht ernstnehmen.

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

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:

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

Valid XHTML 1.0!

Besucherzähler


Latest Update: 18. June 2018 at 15:53h (german time)
Link: osx.realmacmark.de/osx_security.php