0. Technische Aspekte von Mac OS X Inhaltsverzeichnis

0.10 OS X Viren

Eines der am heißesten diskutierten Sicherheitsthemen: Viren für OS X: Gibt es welche, wird es welche geben, sind sie möglich? Warum gibt es sie auf anderen Systemen, warum nicht "bei uns"?

Stichwort-Liste

0.10.1 Einleitung

Über Viren für OS X wird seit vielen Jahren spekuliert. Mir sind jedoch keine Autoren bekannt, die sich für ihre Artikel den Quellcode eines Virus angesehen oder diesen ausprobiert haben. Selbst Sicherheitsfirmen veröffentlichten bestenfalls vage Berichte über Konzeptviren. Eine Analyse der technischen Machbarkeit wurde praktisch nie gemacht. Die Frage, warum "nichts passiert", wurde gerne und oft mit dem Scheinargument Marktanteil beantwortet und von mir widerlegt. Allerdings zwingt dies zur Beantwortung einer anderen Frage: Woran liegt es denn sonst? Die Antwort ist vielschichtig und wurde meines Wissens bislang nie vollständig gegeben.

Ich habe für diesen Artikel über mehrere Jahre verteilt recherchiert. Dabei befragte ich einen international anerkannten und sehr erfahrenen Entwickler, der auf allen größeren Systemen Kenntnisse bezüglich der Machbarkeit und der Ausbreitungsmöglichkeiten hat. Anschließend habe ich die unterschiedlichen Situationen, die Viren auf den verschiedenen Systemen vorfinden, analysiert. Aspekte waren dabei die nicht gleichen Binärformate und ihre Auswirkung und die Verbreitungsmöglichkeiten im Dateisystem. Ich habe verfügbare Konzeptviren bekannter Hacker getestet. Ich habe außerdem mit einem Viren-Autoren, der für verschiedene Systeme Viren geschrieben hat, über seinen OS X-Virus gesprochen, nachdem ich den Virus ausprobiert hatte.

Bei diesen Forschungsarbeiten kommt man leicht in den Verdacht, einer von den Bösen zu sein, aber das bin ich nicht. Mein Interesse ist rein akademisch und technisch. Wenn man die Möglichkeiten und Grenzen von Viren kennen will, muß man verfügbare Exemplare testen, bei Bedarf mit den Autoren sprechen und andere erfahrene Leute befragen.

0.10.2 Aufgabenstellung

Ein Virus ist ein Programm, das ein anderes Programm infizieren kann. Infizieren bedeutet, daß es die ausführbare Datei des Opfers verändert und darin eigene Anweisungen ablegt, die beim nächsten Start des Opfers ausgeführt werden. Das so infizierte Opfer versucht dann typischerweise seinerseits weitere Programme zu infizieren. Siehe auch Sorten von Schädlingen.

Ein Virus muß also zwei Aufgaben lösen: Er muß eine Binärdatei des Zielsystems so infizieren können, daß sie lauffähig bleibt und den zusätzlichen Code ausführen kann. Und er muß schreibbare Binärdateien finden, die ihrerseits Schreibrechte auf andere Binärdateien haben. Die infizierten Dateien müssen ihrerseits weiter lauffähig bleiben und zusätzlich zu ihrer ursprünglichen Arbeit auch selbst weitere Dateien infizieren können, damit die Verbreitung nicht nach einem Sprung beendet ist.

Ein Sonderfall sind Shell-Skripte. Sie sind keine Binärdateien, sondern reiner Klartext und durch einen Virus leicht um zusätzliche Anweisungen zu ergänzen, falls er Schreibrechte darauf hat.

0.10.3 Schwierigkeitsgrad 9.5 von 10

Gerüchte sagen, daß es "einfach" wäre, einen Virus für OS X zu schreiben. "Einfach" bedeutet in diesem Fall, daß sich jemand ein halbes Jahr hinsetzt und bezahlt Vollzeit daran arbeitet und seinen angeblichen Erfolg dann nicht veröffentlicht hat. Gerüchte halt, die sich bei näherem Hinsehen schnell relativieren. Auf anderen Plattformen hat es nie Gerüchte über Viren gegeben, sondern Viren.

In einem Artikel der Baltimore Sun bin ich auf Burt Janz aufmerksam geworden. Er ist seit 1982 professioneller System-Level-Programmierer (Betriebssystem-Kerne) und hat für alle größeren Betriebssysteme entwickelt, beispielsweise Windows, OS/2 und verschiedene Unix-Systeme inklusive OS X. Er hat 1975 sein eigenes System entwickelt und bereits Ende der 70er mit frühen Unix-Formen experimentiert. Er und diverse andere Entwickler hatten auf einen Artikel geantwortet, der das übliche Marktanteils-Märchen als Begründung für die fast vollständige Abwesenheit von Viren auf Unix beziehungsweise OS X gebracht hatte.

Burt sagte, daß es zwar nicht unmöglich wäre, einen OS X-Virus zu programmieren, der Schwierigkeitsgrad dafür jedoch mindestens 9,5 auf einer Skala von 1 bis 10 sei. Noch schwieriger wäre es, mit so einem Virus dann das System selbst zu kompromittieren, was er und die anderen zum guten Teil darauf zurückführen, wie Unix Benutzer auf einer Maschine handhabt: Auf OS X hat selbst ein Admin, der allgemeine Programme installieren kann, weder Zugriff auf die Bereiche der anderen Benutzer noch auf das System. Der allein dazu befähigte Root kann sich standardmäßig nicht mal anmelden. Aufgrund dieser Zugriffseinschränkung ist der Einfluß jeder Form von Schadprogramm auf den betroffenen Benutzer eingeschränkt. Unter Windows war das nie so und ist auch heute mit mit UAC nicht anders.

Auf Windows kann ein Schadprogramm maximalen Schaden anrichten und sein Überleben und Verbreiten gut sichern. Micosoft hat zwar in den letzten Jahren Schritte unternommen, die Situation zu verbessern, leidet jedoch weiterhin an dem Problem, daß Windows immer noch auf einer Architektur basiert, in der Sicherheit keine Rolle spielte, und bei der nicht wie im Falle von OS X Sicherheit ein Entwurfsziel von Anfang an war.

Das war mir alles schon bekannt und ich wollte von ihm wissen, ob es noch mehr technische Gründe gibt. Dazu sagte er unter anderem:

0.10.4 Praxis-Beispiel: Virus MachoMan running...

Es gibt einen Virus aus dem Jahr 2006, geschrieben von "roy g biv". Sein Pseudonym besteht aus den Anfangsbuchstaben der englischen Namen für die Regenbogenfarben. Subtiler Humor ist mir bei Hackern schon öfters aufgefallen. Der Virus heißt "MachoMan" und wurde in der Presse und von den Antiviren-Firmen meistens falsch benannt als "Macarena".

Der Virus wurde von ihm in einer Intel- und einer PowerPC-Version geschrieben, die sich im Quelltext deutlich unterscheiden.

Man kann den Quelltext von MachoMan auf Intel-Tiger übersetzen und die ausführbare Binärdatei erzeugen. Auf Leopard und Schnee-Leopard scheitert das mit einem Fehler:

gcc -arch i386 machoman.s -o machoman
ld: in /var/folders/s2/s260eAK7HDSt8wEJO+yh7U+++TM/-Tmp-//ccC9YLD6.o, in section __TEXT,__text reloc 0: bad length for GENERIC_RELOC_SECTDIFF
collect2: ld returned 1 exit status

Ich habe mir die mutmaßliche Stelle im Quelltext des Systems angesehen, die anscheinend dafür sorgt:

case GENERIC_RELOC_LOCAL_SECTDIFF:
{
if ( !nextRelocIsPair ) {
warning("GENERIC_RELOC_SECTDIFF missing following pair");
break;
}
x86::ReferenceKinds kind = x86::kPointerDiff;
uint32_t contentAddr = 0;
switch ( sreloc->r_length() ) {
case 0:
case 3:
throw "bad length for GENERIC_RELOC_SECTDIFF";

Und "roy g biv" antwortete mir daraufhin, daß sein Vorgehen anscheinend mit der aktuellen Version verhindert wird.

Die auf Tiger übersetzte Version ist allerdings nicht nur auf Tiger lauf- und funktionsfähig, sondern auch auf Leopard und Schnee-Leopard. "MachoMan" ist ein Virus, der vorführt, wie Mach-Objekte (Mach-O-Binaries) infiziert werden können. Er richtet keinen Schaden an, sondern kopiert sich in Binärdateien des gleichen Typs (i386 oder ppc) je nach Version. Binärdateien, die "universal" sind, also Code für mehr als einen Prozessortyp enthalten, ignoriert er. Ebenso werden bereits infizierte Dateien ignoriert. Der Virus beschränkt sich freiwillig auf Dateien, die er in seinem Verzeichnis findet.

Der Autor kommentiert seine Arbeit ausführlich und beschwert sich, daß für so wenig Code so viel Arbeit nötig war. Er hat mehrere Wege ausprobiert, aber lange Zeit führte keiner zum Erfolg. Er hat schon diverse Viren für andere Systeme geschrieben und fand es ungleich schwerer, einen für OS X zu schreiben.

Es wäre möglich, diesen Virus als Vorlage zu nehmen, und einen zu schreiben, der nicht so artig ist. Allerdings müßte die Entwicklung auf Intel-Tiger stattfinden. Diese Systemversion wurde jedoch nie frei verkauft, sondern lag lediglich den ersten Intel-Macs bei. Eine andere Möglichkeit wäre, Compiler und Linker aus jener Zeit zu verwenden. Auf jeden Fall ist das keine ideale Entwicklungs-Voraussetzung.

0.10.5 Praxis-Beispiele: Mach_Cat und Resource-Fork Konzept-Viren

Ein etwas primitiverer Ansatz wurde von einem anderen Hacker, Neil "Nemo" Archibald, im Jahr 2005 für zwei Konzeptviren gewählt. Neil berichtet, daß viele seiner Ideen, Binärdateien auf OS X zu infizieren, mit einer Kernel-Panic quittiert wurden, also scheiterten. Letztendlich probierte er dann, zusätzlichen Code nicht in die angegriffene Binärdatei zu schreiben, sondern an die Binärdatei (nach einer Idee von Silvio Cesare) oder die Resource Fork zu nutzen.

Beide Varianten sind keine echten Viren, weil sie sich nicht in die Opfer-Binärdatei hineinkopieren, sondern die Opfer-Datei verschieben und ihren Platz selbst einnehmen. So wird dann der "Virus" aufgerufen, der anschließend die verschobene Orignal-Binärdatei selbst aufruft. Ein Virus wird Teil der Opfer-Binärdatei und ist zur Laufzeit Teil des Opferprozesses. In diesen beiden Varianten bleiben es jedoch zwei getrennte Binärdateien: "Virus" und Opfer. Der "Virus" übernimmt den Platz des Opfers, wird daher versehentlich gestartet und führt, wenn er fertig ist, mit execve() das Opfer aus.

Neil hat mit diesen beiden Konzepten also keine richtige Infektion von Macho-O Binärdateien vorgeführt. Außerdem verbreitet sich der "Virus" nicht weiter, wenn man eine infizierte Datei startet. Das ist jedoch ein weiteres notwendiges Kriterium, um als Virus zu gelten. Hintergrund ist, daß der Infektor ein Perl-Skript ist, welches nicht Teil des Virus ist, also nicht mit an (erst recht nicht in) das Opfer kopiert wird.

Um also aus diesem Konzept einen richtigen Virus zu machen, hat man noch einige Arbeit vor sich.

0.10.5.1 Anhäng-Variante

In der Anhäng-Variante kopiert der "Virus" die Opfer-Binärdatei an sein Ende und überschreibt anschließend das Original. Man hat also eine Binärdatei, den Virus, die um das Opfer verlängert wird. Beim Start wird die vordere Datei, der Virus ausgeführt. Dieser kopiert sein Anhängsel, das Original, in eine temporäre Datei, die er startet, wenn er selbst seine Aufgabe erledigt hat.

Bei meinem Test funktionierte der Konzept-Virus zwar mit dem beiliegenden Opfer, aber er funktionierte nicht mehr, wenn ich es mit einem einfachen normalen Programm wie ls als Opfer probierte. Das Opfer verhielt sich anschließend nicht mehr normal. Damit ist dieses Konzept wohl noch sehr unausgereift.

0.10.5.2 Resource-Fork-Variante

Bei OS X können Dateisystem-Objekte mehrere Zweige (Forks) haben. Einer davon ist die Resource-Fork. Diese "Virus"-Variante kopiert die Opfer-Binärdatei (deren Daten-Zweig) in die Resource-Fork des Virus und ersetzt anschließend die Opferdatei durch die Datei, die im Daten-Zweig den Virus und im Resourcen-Zweig das Original enthält. Manche Programme speichern Metadaten oder Bilder in dem Resourcen-Zweig. Diese gehen verloren in diesem Fall. So etwas darf bei einem guten Virus nicht passieren. Ansonsten wird auch hier erst der Virus ausgeführt und anschließend startet dieser das Original mit execve() aus seinem Resourcen-Zweig.

0.10.5.3 Zusätzliche Binaries

Neben der Anhäng- und Resource-Fork-Variante gibt es ein weiteres "Viren"-Konzept, das noch weniger "Virus" ist als die beiden vorgenannten Varianten. Wie in 0.10.6.2 Multi-Architektur-Binärdateien beschrieben, besitzt ein "Programm" unter OS X oft mehrere Programme, jeweils eines für jeden unterstützten CPU-Typ. Ein "Programm" ist tatsächlich ein Bündel von Ressourcen und ausführbaren Binärdateien, den eigentlichen Programmen. Für den Benutzer wird dieses Bündel jedoch als eine Einheit dargestellt. Die sogenannte "fette" Binärdatei, die aus mehreren Binärdateien für unterschiedliche Plattformen besteht, kann soviele Binärdateien enthalten wie der Programmierer möchte.

Die Idee für diese "Virus"-Art ist nun, eine weitere Binärdatei hinzuzufügen und diese als die passende für den aktuellen CPU-Typ anzugeben.

Gefragt, warum sonst niemand auf diese Idee, die er "St. Englmar" nennt, gekommen ist, soll er gesagt haben, daß es einfach zu wenig Entwickler mit entsprechender Erfahrung auf dem Mac gäbe. Das ist natürlich eine gewagte These, da die dicken Binärdateien etwas sind, was jeder Entwickler auf OS X kennt, denn man kommt daran nicht vorbei, wenn man sich entscheiden muß, für welche Plattformen man sein Programm compilieren möchte.

Dieses "Viren"-Konzept verändert jedoch keine bestehenden Binärdateien, es fügt nur eine weitere hinzu. Eine Virus-Infektion erfordert, daß man seinen Code in eine bestehende Opfer-Binärdatei hineinbringt. Eine weitere Binärdatei daneben zulegen, ist keine Virus-Infektion.

Da es sich um eine zusätzliche Binärdatei handelt, kann man dies auch leicht mit einem Befehl wie lipo -detailed_info /Applications/Safari.app/Contents/MacOS/Safari erkennen.

0.10.6 Was hält solche Viren auf OS X auf?

Es gibt verschiedene Hürden, die das Schreiben eines Virus für OS X schwieriger machen als für einige andere Systeme. Und es gibt weitere Hürden, die einen funktionsfähigen Virus auf OS X in seiner Wirkung einschränken.

0.10.6.1 Schwieriger zu infizierendes Binärformat

Als erstes stoßen Virenautoren auf die Schwierigkeiten, überhaupt einen funktionsfähigen Virus zu schreiben, also eine Binärdatei auf diesem System prinzipiell technisch korrekt zu infizieren.

Windows verwendet das PE-Format, das auf dem veralteten COFF-Format früher Unix-Versionen basiert. Ausführbare Dateien im PE-Format lassen sich laut Burt mit einer beliebig großen Anzahl von Werkzeugen knacken. Es gibt viele bekannte und benutzte Wege, um eine PE-Datei mit einem Virus zu infizieren.

Unix hat sich weiterentwickelt, das PE-Format hinter sich gelassen und so ziemlich überall durch das ELF ersetzt. Allerdings gab es auch für dieses Format echte Viren, die es erfolgreich infizieren und sich replizieren konnten.

OS X benutzt das Mach-O-Format. Es ist ein komplizierteres Format, für das noch keine wirklich praxistaugliche Infektionsmöglichkeit gefunden wurde. Wie ich weiter oben dokumentiert habe, bissen sich bislang alle möglichen Leute so ziemlich die Zähne daran aus.

0.10.6.2 Multi-Architektur-Binärdateien

Es gibt auf OS X in der Regel nicht "die" Binärdatei eines Programms, das der Virus infizieren kann. Da OS X mehrere Prozessortypen gleichzeitig unterstützt, haben haben die allermeisten Programme sogenannte Fat-Binaries. Dies sind spezielle Archive, in denen verschiedene Binärdateien für unterschiedliche Prozessortypen liegen. Es gibt Programme, die Binärdateien für 32-Bit-PowerPC, 64-Bit-PowerPC, 32-Bit-Intel und 64-Bit-Intel enthalten.

Die von mir ausprobierten Viren kamen nicht mit Fat-Binaries zurecht. Sie konnten nur Programme infizieren, die keine Archive (Fat-Binaries) waren, sondern pure Binärdateien für einen bestimmten Prozessor (im Fall der MachoMan-Varianten), oder sie verloren alle nicht-nativen Binärversion des Opfers und änderten das Verhalten des Opfers (im Fall der Konzeptviren). Die Handhabung von Multi-Architektur-Binärdateien ist zwar mit den vom Betriebssystem gestellten Hilfsprogrammen (ditto beispielsweise) einfach möglich, aber die Viren sind typischerweise in Assembler geschrieben, der in C eingebettet ist. Auf dem Niveau auch noch die Behandlung von Archiven (Multi-Architektur-Binärdateien) nachzuprogrammieren, ist aufwendig.

Selbst die Variante, die eine weitere Binärdatei zu dem "Fat Binary" hinzufügt, kommt in diese Schwierigkeiten, da sie sich selbst als passend ausgeben muß, dabei jedoch auch wirklich für verschiedene CPUs passend sein muß. Damit genügt es schon nicht mehr, nur eine einzelne Binärdatei hinzuzufügen.

0.10.6.3 Fehlende Schreibrechte

Ein Virus muß, wenn man das Dateiformat prinzipiell infizieren kann, das nächste Problem lösen: Weitere ausführbare Dateien finden, auf die er Schreibrechte hat.

Dem typischen OS X-Benutzer und somit einem potentiellen Virus fehlen die Schreibrechte, die dem Virus eine direkte Verbreitung ermöglichen. Allerdings geht es indirekt über /Applications und /Library. Das wiederrum kann zumindest zeitweise aufgehalten werden, wenn man als normaler Benutzer arbeitet. Gut ist, daß man sich nie als root einloggen muß und damit das gesamte System für den Virus preisgibt. Bei anderen Unices, bei denen nicht die Admin-Gruppe, sondern root Programme installieren muß, besteht eine wesentlich bessere Ausbreitungsmöglichkeit. Insbesondere gilt das für Windows, bei dem der typische Benutzer systemweite Schreibrechte hat; ja, auch mit der UAC ist das der Fall.

Für Shell-Skript-Viren gibt es die zusätzliche Herausforderung, überhaupt ein anderes Skript zu finden, auf das der typische Benutzer Schreibrechte hat. Bei einer normalen Systeminstallation habe ich nichts passendes gesehen. Manche später installierten Programme enthalten jedoch auch Skripte in ihrem Paket.

Was im Finder wie ein Programm (.app) aussieht, ist tatsächlich ein Paket, ein Verzeichnis, das Ressourcen und die Binärdatei und unter Umständen auch Skripte enthält.

0.10.6.4 Signierte Programme

Angenommen, man kann also das Dateiformat infizieren und hat auch Schreibrechte auf andere ausführbare Dateien, dann gibt es eine weitere Hürde: Die Infektion darf nicht auffallen. OS X verlangt von seinen Entwicklern seit 10.5, daß alle Programme signiert werden. Unsignierte Programme fallen negativ auf, weil das System sie dann anders handhaben muß, was für den Benutzer nerviger ist durch häufigeres Nachfragen.

Jede Veränderung an einem signierten Programm durch einen Virus oder was auch immer fällt dem System auf. Es verhindert jedoch auf OS X dann noch nicht prinzipell den Start. Auf iOS, das ein mobiler Ableger von OS X ist, jedoch schon. Veränderten und damit ungültig signierten Programmen wird der Start verweigert (es sei denn man "jailbreakt" das System).

0.10.7 Zusammenfassung

Das Binärformat von OS X ist schwieriger zu infizieren. Außerdem, und das ist eigentlich der wichtigere Punkt, könnte ein Virus (auch als Shell-Skript) sich wegen der strengen Unix-Benutzer- (und System-) Trennung weder besonders gut weiterverbreiten noch verstecken. Er hätte weniger Schreibrechte sowohl im Dateisystem als auch bezüglich dynamischer Bibliotheken im Speicher. Und spätestens dann, wenn auf OS X veränderte Dateien überhaupt nicht mehr ausgeführt werden können so wie es iOS schon praktiziert, dann ist die Ära der Viren auf OS X zuende bevor sie überhaupt jemals angefangen hat.

Kurzfassung: Virenautoren treffen auf OS X nur auf Probleme. Probleme, die sie auf Windows nie hatten.

2011-07-08: Promi-Hacker raten ab von AV-Software am Mac.

Valid XHTML 1.0!

Besucherzähler

Latest Update: 11. September 2015 at 19:51h (german time)
Link: cnc.realmacmark.de/osx_viren.php