daily.out

2008-12-30

Netzwerk-Einstellungen in Schnee-Leopard: 32-Bit und 64-Bit

Zur Zeit kursiert ein Bildschirm-Photo eines Warnhinweises der Netzwerk-Einstellungen in Schnee-Leopard, die besagt, die System-Einstellungen müssen im 32-Bit-Modus neugestartet werden, um die Netzwerk-Einstellungen zu verwenden.

Ein Bild stört mehr als tausend Worte

Schnee-Leopard, also Version 10.6, befindet sich zur Zeit in der Entwicklung und das Veröffentlichen von Bildschirm-Photos ist den Leuten, die Zugang dazu haben, vertraglich verboten. Irgendwer hat sich nicht daran gehalten und das Bild des bislang unfertigen Betriebssystems löste anschließend auf diversen Seiten und in allerlei Foren unnötige Verwirrung und Spekulationen aus.

Ein schönes Mißverständnis auf apfeltalk beispielsweise ist, daß Felix schreibt:

Korrekt ist, daß das "System" die "System-Einstellungen" neustarten möchte dafür. Der Anwender hat damit nichts zu tun. Das erkennt man leicht, wenn man den englischen Text in dem Photo richtig übersetzt. Man würde es allerdings auch blind wissen, wenn man die Details kennt, wie OS X die fetten Binärdateien (fat binaries), die Apple "Universal Binaries" nennt, handhabt.

Start von fetten Binärdateien

Die fetten Binärdateien enthalten mehrere ausführbare Versionen des gleichen Programmtextes in einer einzigen Datei. Der Anwender kann nicht festlegen, welcher Teil der Datei ausgeführt wird. Er kann nur das Programm starten und das System wählt die passende Variante. Und genau das passiert auch in dem Szenario, was das diskutierte Bildschirm-Photo andeutet: Das System bemerkt, daß es die falsche Variante ausführt und möchte nun lieber die andere, passende Variante starten. Der Anwender darf sagen, ob er der dazu nötigen Beendigung der gerade laufenden Version zustimmt. Denn es wäre doch nicht sehr schön, wenn das System dem Anwender einfach ein von ihm gestartetes Programm beendet.

Praktisches Beispiel für eine fette Binärdatei

Hier ist ein praktisches Beispiel für eine fette Binärdatei, das jeder selbst ausprobieren kann. Es enthält ausführbare Versionen für vier verschiedene Prozessor-Typen. Zuerst zeige ich den Programmtext.

KeyWest:~ macmark$ cat hello.c
/* Hello World program */

#include<stdio.h>

main()
{
    printf("Hello World");
}


Nun erstelle ich daraus eine übersetzte, ausführbare Datei, die vier verschiedene Versionen enthält für vier verschiedenen Prozessor-Architekturen:

KeyWest:~ macmark$ gcc -arch ppc -arch ppc64 -arch i386 -arch x86_64 -c hello.c

Dann schauen wir uns das Ergebnis mal an.

KeyWest:~ macmark$ file hello.o
hello.o: Mach-O universal binary with 4 architectures
hello.o (for architecture ppc7400): Mach-O object ppc
hello.o (for architecture ppc64): Mach-O 64-bit object ppc64
hello.o (for architecture i386): Mach-O object i386
hello.o (for architecture x86_64): Mach-O 64-bit object x86_64

Wir können auch noch genauer hineinschauen.

KeyWest:~ macmark$ lipo -detailed_info hello.o
Fat header in: hello.o
fat_magic 0xcafebabe
nfat_arch 4
architecture ppc7400
    cputype CPU_TYPE_POWERPC
    cpusubtype CPU_SUBTYPE_POWERPC_7400
    offset 4096
    size 744
    align 2^12 (4096)
architecture ppc64
    cputype CPU_TYPE_POWERPC64
    cpusubtype CPU_SUBTYPE_POWERPC_ALL
    offset 8192
    size 852
    align 2^12 (4096)
architecture i386
    cputype CPU_TYPE_I386
    cpusubtype CPU_SUBTYPE_I386_ALL
    offset 12288
    size 512
    align 2^12 (4096)
architecture x86_64
    cputype CPU_TYPE_X86_64
    cpusubtype CPU_SUBTYPE_X86_64_ALL
    offset 16384
    size 728
    align 2^12 (4096)

Man erkennt hier, daß jeweils die Stelle (offset) vermerkt ist, an der jeweils eine andere Variante des übersetzten Programmes innerhalb der Datei zu finden ist.

Wird diese ausführbare Datei nun gestartet, dann wählt das System die am besten passende Variante innerhalb der Datei und führt sie aus.

So funktionieren die System-Einstellungen

Die System-Einstellungen sind ein Programm, das zur Laufzeit (die coolen Kids sagen "dynamisch") weitere Programmteile (die coolen Kids sagen "Plug-ins") nachladen kann. Jede einzelne Einstellungs-Option ist ein solches Plug-in.

Ein 32-Bit-Programm kann jedoch nur Plug-ins verwenden, die auch in 32 Bit vorliegen. Analog kann ein 64-Bit-Programm nur Plug-ins verwenden, die in 64 Bit vorliegen.

Weil Plug-ins Teil des laufenden Programmes (Prozesses) sind, wenn sie geladen wurden, gibt es diese Bedingung auf OS X. Allerdings kann OS X 32-Bit-Programme und 64-Bit-Programme gleichzeitig ausführen. Die Einschränkung gilt also nur innerhalb eines Programmes.

Ein Ziel von Version 10.6 "Schnee-Leopard" ist, weitere Systembestandteile in 64 Bit verfügbar zu machen. Das ist insbesondere auf Intel-Prozessoren sinnvoll, weil diese bestimmte leistungssteigernde Merkmale (zusätzliche Register beispielsweise) nur 64-Bit-Programmen zugänglich machen. Beim 64-Bit- PowerPC konnten hingegen Programme, die im 32-Bit-Modus laufen, die gleichen Prozessor-Ressourcen nutzen wie im 64-Bit-Modus. Da aber bei 64-Bit-Intel-Prozessoren nur 64-Bit-Programme den Prozessor ganz nutzen können, ist es sinnvoll, sämtliche Programme auf 64 Bit umzustellen, weil die dann zusätzlich verfügbaren Prozessor-Ressourcen auch solche Programme beschleunigen, die gar keine 64-Bit-Adressierung benötigen.

Die System-Einstellungen und ihre Plug-ins verfügen bis 10.5 nur über 32-Bit-Versionen für Intel und PowerPC.

KeyWest:~ macmark$ system_profiler -detailLevel mini SPSoftwareDataType
Software:

    System Software Overview:

      System Version: Mac OS X 10.5.6 (9G55)
      Kernel Version: Darwin 9.6.0
      Time since boot: 22 minutes

KeyWest:~ macmark$ cd /Applications/System\ Preferences.app/Contents/MacOS/
KeyWest:MacOS macmark$ file System\ Preferences
System Preferences: Mach-O universal binary with 2 architectures
System Preferences (for architecture i386): Mach-O executable i386
System Preferences (for architecture ppc7400): Mach-O executable ppc

KeyWest:~ macmark$ cd /System/Library/PreferencePanes/Network.prefPane/Contents/MacOS/
KeyWest:MacOS macmark$ file Network
Network: Mach-O universal binary with 2 architectures
Network (for architecture i386): Mach-O bundle i386
Network (for architecture ppc7400): Mach-O bundle ppc

Apple fügt offenbar nun auch für die System-Einstellungen und ihre Plug-ins mindestens eine 64-Bit-Version für die beiden Prozessor-Architekturen hinzu, genauer gesagt mindestens für die Intel-Version.

Wenn beim aktuellen Entwicklungs-Stand von 10.6 nur das System-Einstellungen-Programm selbst zusätzlich eine 64-Bit-Version in seiner fetten Binärdatei hat und beispielsweise das "Netzwerk"-Plug-in nicht, dann wird "System-Einstellungen" auf einem 64-Bit-Prozessor automatisch in der 64-Bit-Version gestartet, weil diese am besten paßt. Klickt man dann jedoch auf "Netzwerk", was nur unpassende, weil noch nicht um zusätzliche 64-Bit-Versionen ergänzte, ausführbare Programme enthält, dann kann das "Netzwerk"-Plug-in nicht geladen werden und man kann oben erwähnte Meldung erwarten.

Unterstützung alter Versionen in Schnee-Leopard

Es ist jedoch davon auszugehen, daß Apple von allen Plug-ins der System-Einstellungen auch 64-Bit-Version erstellen wird. Wie einfach das prinzipiell ist, kann ja jeder mit obigen Beispielen nachvollziehen.

Ebenso einfach wäre es auch, weiterhin die PowerPC-Familie zu unterstützen, denn OS X enthält nur verschwindend wenig System-Programme, die auf einzelne Prozessoren zugeschnitten sind.

2008-12-21

MacBook nicht gehackt in zwei Minuten

Was war wirklich passiert?

Apples Fehler

OS X verwendet viele quelloffene andere Projekte, um das Rad nicht selbst neu zu erfinden. Eines davon ist die PCRE-Bibliothek. Diese wird für die JavaScript-Engine in Webkit und damit in Safari verwendet, um mit "regulären Ausdrücken" zu arbeiten.

Da solche quelloffenen Komponenten, wenn sie frei verfügbar sind, auch von vielen verwendet werden, ist die Chance hoch, mögliche Fehler auszumerzen. So wurden in dieser Bibliothek in 2007 diverse Fehler behoben und wer diese Bibliothek einsetzt, tut gut daran, eine jeweils möglichst fehlerbereinigte Version zu verwenden.

Apples aktualisierte seine Version leider erst, nachdem Charlie Miller einen bekannten Fehler in dieser Bibliothek nutzte, um den Safari auf dem iPhone, das gerade frisch auf dem Markt war, medienwirksam anzugreifen. Apple korrigierte alle zu der Zeit verfügbaren und betroffenen Version des Betriebssystems.

Als im letzten Quartal von 2007 dann Leopard fertiggestellt wurde, war eine veraltete Version der PCRE-Bibliothek enthalten. Das liegt daran, daß in den Entwicklungszweig von Leopard einige Aktualisierungen von externen Bibliotheken, die in Tiger schon eingebaut waren, nicht eingepflegt wurden. In Leopard tauchten leider einige schon früher behobene Fehler erneut auf.

Apples Fehler bestand also darin, nicht schnell genug die korrigierten Versionen externer Bibliotheken einzusetzen. Die veraltete Version in Leopard wurde erst in 2008 behoben, nachdem Charlie Miller auch in Leopard die gleiche fehlerhafte PCRE-Bibliothek nochmals ausnutzte, um auch darauf Safari anzugreifen. Wieder medienwirksam und diesmal in einem unter anderem von Microsoft gesponserten öffentlichem Wettbewerb.

Ein schönes Beispiel für reißerische Negativ-Artikel über OS X, denen man bei Kenntnis der Details nachweisen kann, daß fast nichts darin stimmt und vor allem die Schlagzeile vollkommener Unfug war, ist diese Geschichte vom 28. März 2008. Man konnte haufenweise Artikel wie diesen lesen:

Auch wurde gerne so formuliert:

Was stimmt an diesen Aussagen nicht?

Zero-Day-Exploit?

Ein Zero-Day-Exploit ist ein Programm, das eine bisher unbekannte Sicherheitslücke am Tag ihrer Veröffentlichung ausnutzt. Das ist hier nicht der Fall, denn der zugrundeliegende Bug wurde schon 2007 veröffentlicht. Charlie Miller hat also keinen Zero-Day-Exploit gebracht, wie es der Wettbewerb, an dem er teilnahm vorschrieb, sondern einen seit Monaten veröffentlichten Fehler genutzt. Damit hat er zu unrecht "gewonnen".

Nur zwei Minuten?

Charlie Miller sagt selbst, daß er nicht allein war und daß es länger dauerte:

Dabei kam Charlie Miller und seinen Kollegen zugute, daß sie die fehlerhafte PCRE-Bibliothek bereits seit einem Jahr gut kannten, weil sie diese ja schon damals für einen fast identischen Angriff ausgenutzt hatten.

Auf dem Wettbewerb hat er dann den Tag abgewartet, der die Nutzung eines Browsers erlaubte, und dann Safari auf einer Seite, die seinen bereits vorbereiteten Exploit nutzte, erfolgreich angegriffen.

Von zwei Minuten kann man daher wohl kaum sprechen, sondern von mindestens einem Jahr Erfahrung mit einem vergleichbaren Angriff und wochenlanger gezielter Vorbereitung für eine weitere Variante eben dieses Angriffs.

Zuerst gehackt?

Shane Macaulay, der Vista bei dem Wettbewerb angriff, hatte nicht damit gerechnet, daß auf dem Rechner das Service Pack 1 installiert war. Er mußte sich daher vor Ort noch ein paar weitere Tricks ausdenken, um die von ihm genutzte Sicherheitslücke ausnutzen zu können.

Auf der einen Seite hatten wir also Charlie Miller, der nachweislich gut und lange vorbereitet zum Wettbewerb kam, und auf der anderen Seite Shane Macaulay, der offenbar nicht einmal die Regeln des Wettbewerbs gelesen hatte, in denen stand, wie die Rechner ausgerüstet sind.

Neben der besseren Vorbereitung war möglicherweise auch eine deutlich höhere Motivation auf der Seite von Charlie Miller im Spiel: Er soll angeblich gesagt haben, er sehe seine Lebensaufgabe darin, die Sicherheit von Apple-Produkten zu diskreditieren.

Rechner unter Kontrolle?

Der Exploit für Safari ermöglicht Programmausführung unter dem Benutzer, der gerade mit Safari arbeitet. Um den Rechner zu kontrollieren, müßte er an Systemrechte damit gelangen können. Er hatte jedenfalls definitiv nicht den Rechner unter Kontrolle, sondern "nur" dem Benutzer etwas untergeschoben.

Ferner suggeriert "den Rechner hacken", daß der Angreifer allein tätig ist. Tatsächlich ist er aber darauf angewiesen, daß der Benutzer eine eigens dafür angelegte Seite besucht und JavaScript dabei aktiviert hat.

Juror auf Seite gelockt?

Die Regeln sahen vor, daß man dem Juror sagen darf, welche Seite er besuchen soll. Von "locken" kann daher keineswegs die Rede sein.

Schlußbemerkungen

Die meisten Artikel über dieses oder ähnliche Sicherheitsthemen sind einfach schlecht oder gar nicht recherchiert. Sie nutzen eine plakative Schlagzeile, die die Klickrate hochtreibt, aber nicht der Wahrheit entspricht. Man sollte also sehr vorsichtig sein, der Presse solche Meldungen ungeprüft zu glauben.

Zweifelsohne hat Apple sich nicht mit Ruhm bekleckert, wenn es darum ging, sicherheitsrelevante Aktualisierungen der verwendeten Bibliotheken so bald wie möglich einzusetzen. Hier könnten sie besser sein.

Ich schreibe bewußt, sie "können" besser sein, weil die praktische Möglichkeit dazu besteht. Diese Möglichkeit hat beispielsweise Microsoft nicht:

Relevanz von Bugs

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. Das geht so weit, daß sie sicherheitskritische Bugs erst nach sieben Jahren beheben können, weil sie das fehlerhafte Design nicht einfach austauschen können. Im Gegensatz dazu lassen sich Bugs wie bei diesem Wettbewerb leicht beheben.

---