daily.out

2011-05-29

launchd/systemd: GNU/Linux übernimmt Innovation von OS X

Seit circa April 2010 gibt es mit systemd eine Version, die das Konzept von launchd auch für GNU/Linux verfügbar macht. So wird systemd beispielsweise in Fedora 14 und 15 verwendet.

Mit Fedora 15 ist systemd nun fester Teil der Basis einer Linux-Distribution. Systemd wurde von Lennart Poettering geschrieben. Lennarts Beschreibung, welche Probleme er mit systemd lösen will, ähnelt ziemlich der von Apples launchd. Launchd wurde im April 2005 mit OS X 10.4 Tiger von Apple eingeführt. Ziemlich genau 5 Jahre später ist diese technische Innovation auch bei unseren GNU/Linux-Kollegen gelandet und noch ein Jahr später, 2011, dort auch etabliert.

Lennart ist voll des Lobes über launchd von OS X: Launchd wäre ein wirklich genialer Entwurf und er bedauert, daß diese tolle Idee bislang nicht eher auch außerhalb von Apple genutzt wurde. Was die Qualitäten von launchd ausmacht, habe ich hier zusammengefaßt.

Er schwärmt davon, daß alle Dienste, ohne daß man Abhängigkeiten explizit definieren muß, ohne Synchronisation parallel gestartet werden können, beziehungsweise, daß sie dynamisch erst bei Bedarf geladen werden. Er beneidet die kurzen Startzeiten von OS X im Vergleich zu GNU/Linux dank dieses Konzeptes. Auf seinem GNU/Linux müssen beim Start 1823 Prozesse gestartet werden, bei OS X hingegen fand er nur 154. Ein dramatischer Unterschied der Arbeitslast beim Bootprozeß. Ein wesentlicher Grund hierfür ist, daß selbst für banale Aufgaben meist erst ein Shell-Skript gestartet werden muß, was im Vergleich zu der trivialen Aufgabe, die das Skript dann löst, ein nicht zu verantwortender Overhead ist. So hat er insgesamt 266 Aufrufe für die Befehle sed, awk, cut und grep während des Bootens gezählt.

Launchd in OS X hält Lennart für eine großartige Innovation, allerdings ist launchd aus seiner Sicht nicht passend genug für GNU/Linux, so daß er zwar das Konzept übernommen hat, aber nicht die Implementierung. Die wäre auch möglich, denn launchd ist frei verfügbar und es gibt keine gängelnden Einschränkungen, wenn man den Code ändern und in einem anderen System einsetzen möchte.

Fedora verwendet bereits systemd in Version 14 optional und in Version 15 fest. Und wie man so hört, will openSUSE ihn auch später nutzen, Mandriva 2011 wird ihn offenbar einsetzen und Arch Linux, Gentoo und Debian experimentieren damit.

2011-05-21

Macintosh-Weltuntergang

Die Jünger des Marktanteils kommen in Erklärungsnot: Der prozentuale Anteil des Macintosh hat sich in den letzten Jahren verdoppelt und liegt nun in dem Bereich, für den eine Epidemie an Schad-Software vorhergesagt wurde. So jedenfalls lehrt Ed Bott auf Englisch

und auf Deutsch.

Kleines Problem dabei: Die Malware – sehnsüchtig erwartet – will einfach nicht kommen. Sie soll aber kommen – laut Ed Bott. Warum? Weil für die Marktanteils-Jünger der Grund, warum es so gut wie keine Macintosh-Malware gibt, der Marktanteil ist. Nun ist jedoch die Situation gekommen, in der die Prophezeihung eintreten müßte und die Macintosh-Welt von einer Flut Malware überrollt werden sollte. Und nichts besonderes ist passiert: Es gab halt den jährlichen neuen Trojaner und ein Russe versucht, seinen Baukasten für Trojaner in Untergrund-Foren zu verkaufen.

Ed Bott erinnert mich an einen anderen Prediger aus den USA: Harold Camping. Er hat auch einen Weltuntergang vorhergesagt – Für den 21. Mai 2011:

Wie es ausschaut, sind beide Apokalypsen ausgefallen.

Ed Bott ist ja auch nicht besonders helle, was Sicherheit angeht: Er glaubt, daß Apple mit der Klassifizierung "arbitrary code execution" "no user interaction required" meint. Tatsächlich bedeutet "arbitrary code execution" jedoch, daß ein Bug einen Angriff ermöglichen könnte, bei dem im Kontext des angegriffenen fehlerhaften Programmes Code des Angreifers ausgeführt werden könnte. Witzigerweise zählt Ed Bott dann 23 Beispiele ("Page 2: 23 flaws, no user interaction required") aus einem Bugfix-Bericht von Apple auf, die alle Benutzeraktion erforderten: Runterladen, Anschauen, Besuchen. Der User muß immer ein Dokument (Webseite, Bild, Dokument) aufrufen. Alles, was keine Nutzeraktion benötigt, wäre ein Wurm. Dafür macht man den Rechner an, geht Brötchen kaufen, und wenn man zurückkommt, ist der Rechner infiziert. Windows-User kennen das.

Anschließend bringt er auch die Darstellung, der Mac würde bei Pwn2Own, dem Fake-Wettbewerb, immer zuerst übernommen. Dabei ist es eine getürkte Auslosung der Reihenfolge, die dafür sorgt.

An allen Stellen behauptet Ed Bott, das System hätte übernommen werden können. Das ist zwar bei Windows so, weil der typische User Systemrechte hat auch mit der UAC, dem Sicherheits-Plazebo, beim Macintosh jedoch nicht, weil der typische User keine Systemrechte hat.

Ein weiteres Beispiel für seine Unkenntnis in diesem Punkt ist, daß er den (inzwischen behobenen) Bug in Skype so einschätzt, daß man allein dadurch Root-Zugriff bekommen könne. Das ist völliger Humbug, da Skype nicht unter Root läuft. Ed Bott übernimmt dumme Schlagzeilen von anderen, fügt sie bedenkenlos zusammen und hat seinen Weltuntergang. Ob er sich wundert, daß das alles nicht passiert? Deutsche Medien sind da nicht viel besser. Heise erwartet für den Macintosh ebenfalls die Apokalypse, wundert sich jedoch, daß sie nicht kommt und hält darum die Situation für "paradox". Sie ist für Heise paradox, weil Heise die relevanten technischen Ursachen nicht berücksichtigt.

Bezüglich des Trojaner-Baukasten Weyland-Yutani sieht Ed Bott einen Wendepunkt für Malware auf dem Macintosh, da die Bösen den langsamen Niedergang des Windows-Monopols erkennen und auf alternative Plattformen umschwenken würden. Sie würden die Marktbedingungen testen und nur noch auf den richtigen Zeitpunkt warten, um loszuschlagen. Denkfehler dabei: Der Macintosh wird nicht unsicherer, sondern mit jeder neuen Version besser. Der ideale Zeitpunkt wäre also vor 10 Jahren gewesen oder zu Zeiten des "klassischen" Macintoshs. Für das Vorgängersystem gab es tätsächlich mehr Schädlinge und das, obwohl sein Marktanteil noch kleiner war. Es kommt halt nicht auf den Marktanteil an.

John Gruber hat eine schöne Auflistung von ein paar vergangenen Prophezeihungen, die immer das Gleiche verkündeten: "Jetzt geht's los!". Ed Bott meint jedoch, diesmal wäre alles anders, weil mehr Leute beim Apple-Support anriefen wegen dem Trojaner "Mac Defender".

Heise greift das natürlich auf und meckert, daß der Apple-Support von dem Trojaner nichts wissen wolle. Das ist etwas irreführend formuliert, denn Apple kann und will keine Ferndiagnosen am Telefon stellen und dann vielleicht noch wegen Fehlern dabei verklagt werden. Außerdem ist Apple nicht für Probleme zuständig, die der Anwender durch Installation von Dritt-Softare selbst verschuldet hat.

Interessante Randnotiz dazu: Ich habe mal auf das Bild, das eine interne Apple-Anweisung zum Umgang mit solchen Anrufen sein soll, Kantenschärfung angewendet und dadurch wasserzeichenähnliche Angaben zu Datum und Internet-Adressen sichtbar gemacht. Die Adresse liegt tatsächlich in Cupertino und gehört zu Apple.

Nachdem all die Prediger oben versagt haben, will ich mal versuchen, es richtig zu machen. Und es soll natürlich passend zu den Vorurteilen echt Mac-jüngerhaft sein:

Ed Bott und all die anderen Endzeit-Propheten sind mit ihrem grundlegenden fachlichen Unwissen nicht allein. Es gibt da endlos viele Exemplare, die sich zu dem Thema äußern müssen ohne belastendes Fachwissen. Die meisten davon sind überhaupt gar nicht vom Fach. Hier ist zum Beispiel einer ("DAMerrick"), der meint:

C++ ist ganz bestimmt keine der "einfachen" Sprachen. Und Buffer Overflow-Probleme kommen durch die Komplexität, beispielsweise, Format-Strings sicher zu verwenden. Buffer Overflows sind allerdings schon ein C-Problem und sie sind nicht erst bei C++ entstanden.

Java ist eben nicht für Buffer Overflows offen – by design. Man kann nicht über Speichergrenzen hinaus schreiben, denn Java fängt das ab. Beispiel: Einfach mal versuchen, über das Ende eines Java-Arrays hinaus zu lesen oder zu schreiben. Man kann in Java keinen Code schreiben, der anfällig für Buffer Overflows ist. Das geht nur über das Java-Native-Interface, wenn man also eine andere Sprache nutzt, oder über Fehler in der Java-Laufzeitumgebung, die nicht in Java geschrieben wird typischerweise, sondern in C/C++, oder bei Compiler-Fehlern.

Seine Darstellung, von was das Mac-System abstammt, ist auch fehlerhaft. Korrekt ist dies hier, woran man erkennt: Apple nutzt auch verschiedenes von OpenBSD. Und ebenso von TrustedBSD direkt, zum Beispiel die Technik für Sandboxing.

Und natürlich werden Cocoa-Programme in Objective-C geschrieben. Womit denn sonst? Und natürlich ist Objective-C eine voll kompatibele Erweiterung von C. Das ist ja grad das Tolle daran im Gegensatz zu anderen Sprachen, die inkompatibel auf C aufbauen. Warum sollte Apple das "anders sehen"? Völliger Quark. Was er als schlecht hinstellt, ist tatsächlich eine der größten Stärken von Objective-C.

Wenn man sich also weder mit Programmiersprachen noch mit dem System auskennt, kann man nur eins werden: Prophet.

2011-05-11

Trojaner-Baukasten Weyland-Yutani

Das Trojaner-Toolkit ist in Anlehnung an die "Alien"-Science-Fiction-Filme nach der Firma Weyland-Yutani benannt worden, die auf anderen Planeten die Besiedlung durch Menschen vorbereiten sollte. Analog soll dieses Toolkit Macs auf die Benutzung durch Angreifer "vorbereiten".

Situation

Es ist ein Schadprogramm-Baukasten für OS X in Untergrund-Foren aufgetaucht, der sich Weyland-Yutani nennt, und dazu dient, Trojaner zu erstellen, die Benutzereingaben in Webformularen der Browser Firefox und Google Chrome erkennen und abgreifen sollen.

Der kriminelle Programmierer sagt, er plane auch eine entsprechende Version für GNU/Linux und für das iPad.

Der Security-Blogger Brian Krebs wollte mehr über diesen Baukasten erfahren und kontaktierte den Malware-Autor, der das Tool für 1000 US-Dollar verkaufen möchte, in einem russisch-sprachigen Forum. Der Cracker sagte, er warte erstmal damit, Unterstützung für das Form-Grabbing auch noch für Safari in das Toolkit einzubauen, weil er mit diesem Browser zu viele Probleme habe.

Ein Video auf YouTube zeigt, wie eine Paßworteingabe in Firefox auf OS X abgefangen und in der Admin-Seite des Schnüffel-Tools, das in einem Safari-Fenster läuft, angezeigt wird laut der dänischen CSIS Security Group. Die Adreßzeilen von Firefox und Safari sind dabei mit einem schwarzen Balken unkenntlich gemacht worden.

Analyse

Obwohl der Weyland-Yutani mir leider nicht zur Verfügung steht, so daß ich das Tool nicht direkt untersuchen kann, gibt es doch ein paar interessante Anhaltspunkte:

Die Browser Firefox und Google Chrome ermöglichten ihm offenbar einen erfolgreichen Angriff mit seiner Malware. Apples Safari konnte er noch nicht erfolgreich ausspähen, weil er nach eigenem Bekunden auf technische Probleme gestoßen ist. Was mag der Unterschied sein, der einen Angriff auf die Browser unterschiedlich schwierig macht?

Ich habe mir 2010 die verfügbaren handvoll Keylogger für OS X angesehen, die wie die mit Weyland-Yutani erstellten Trojaner versuchen, Benutzereingaben aufzuzeichnen. Im Gegensatz zu dem Baukasten wollen sie jedoch alle Eingaben aller Programme mitschneiden und filtern nicht Browser und ihre Formulareingaben heraus. Die aufgezeichnete Datenmenge ist also erheblich größer. Weyland-Yutani filtert gezielt Web-Formular-Eingaben heraus.

Bei meinen Tests ist aufgefallen, daß normale Eingaben in der GUI und im Terminal problemlos mitgeschnitten werden können. Allerdings hatten die Userland-Tools keine Chance, Paßwortfelder zu erfassen beziehungsweise Eingaben im Terminal, wenn die Option "Secure Keyboard Entry" für die Terminal.app gewählt wurde. Einzig und allein Tools, die als Kernel-Extension (mit Root-Rechten) installiert wurden, konnten alles mitlesen.

Der technische Hintergrund, warum manche Eingaben mitgeschnitten werden können und andere nicht, liegt darin, daß die Möglichkeiten zum Abgreifen der Benutzereingaben aufgrund legaler Anwendungsfälle wie Eingabeunterstützung oder Replay-Tools generell vom System angeboten wird. Während sicherheitskritischer Eingaben kann das Programm jedoch diese "Keylogger"-Schnittstellen vom System abschalten lassen. Das passiert beispielsweise, wenn man die oben genannte Terminaleinstellung wählt oder das Programm ein sicheres Eingabefeld der OS X-APIs verwendet. Man kann es jedoch auch explizit an- und abschalten.

Es gab vor ein paar Jahren schon einmal den Fall, daß Tastatur-Recorder mit anderen Browsern wie dem Internet-Explorer auf OS X keine Probleme hatten, "sichere" Eingaben abzugreifen, während sie bei Safari, der die APIs korrekt nutzte, nicht ans Ziel kam. Möglicherweise liegt heute wieder ein ähnlicher Fall vor.

Interessanterweise widerlegt auch diese Situation das verbreitete Marktanteilsmärchen: Der Malware-Autor greift nicht Safari, den Browser mit dem größten Marktanteil auf der Plattform an, sondern die beiden hier deutlich weniger genutzten Firefox und Chrome, weil sie ihm technisch weniger Schwierigkeiten machen. Viele halten Firefox oder Chrome für sicherer als Safari – eine Vermutung, die hier keinen Halt findet.

---