daily.out

2010-01-13

Sieben Monate nutzlose Exploits

Ein Exploit oder auch Proof of Concept ist ein Beispiel für das Ausnutzen eines Programmierfehlers. Damit weist man das Problem reproduzierbar nach. Kürzlich wurden jedoch Exploits veröffentlicht, die diesen Namen nicht verdienen: Sie funktionieren nicht. Das heißt, die Exploits laufen, provozieren jedoch keinen Fehler, nicht einmal den, den sie provozieren sollten laut Dokumentation:

In beiden Konzept-Beispielen wird angeblich ein unzulässiger Speicherzugriff provoziert, der das Beispielprogramm vorzeitig mit einem Fehler abbrechen läßt. Das ist jedoch nicht der Fall: Beide Programme laufen sauber durch ohne einen Fehler zu provozieren.

Die Programme sind in Abschnitt 2 des Berichtes gelistet:

- --- 2. Proof of Concept (PoC) ---

Das erste soll einen Pufferüberlauf provozieren:

- --- 2.1. strtod(3) buffer overflow example PoC ---
#include <stdio.h>
#include <stdlib.h>

int main ()
{

char number[] = "0.1111111111...11", *e;

double weed = strtod(number, &e);

printf("grams = %lf\n", weed);
return 0;

}

Maksymilian Arciemowic schreibt, daß er auf folgenden Fehler läuft:

(gdb) r
Starting program: /Volumes/ARC/299
Reading symbols for shared libraries ++. done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x0039f000
0x002271ac in __diff_D2A ()

Das ist jedoch bei mir nicht der Fall mit OS X 10.6.2:

KeyWest:bin macmark$ cat poc.c #include <stdio.h>
#include <stdlib.h>

int main ()
{

char number[] = "0.1111111111...11", *e;

double weed = strtod(number, &e);

printf("grams = %lf\n", weed);
return 0;

}

KeyWest:bin macmark$ gcc -Wall poc.c -o poc
KeyWest:bin macmark$ ./poc
grams = 0.111111
KeyWest:bin macmark$ gdb poc
GNU gdb 6.3.50-20050815 (Apple version gdb-1346) (Fri Sep 18 20:40:51 UTC 2009)

This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries .. done

(gdb) r
Starting program: /Users/macmark/bin/poc
Reading symbols for shared libraries +. done
grams = 0.111111

Program exited normally.

Das zweite soll ebenfalls einen Pufferüberlauf provozieren:

--- 2.2. atof(3) buffer overflow example PoC ---
#include <stdio.h>
#include <stdlib.h>

int
main()
{
char s[]="111.111111...11";

float a=atof(s);
printf("%f",a);
}

Maksymilian Arciemowic schreibt, daß er damit auf folgenden Fehler läuft:

Bus error

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x0039f000
0x00227017 in __lshift_D2A ()

Das ist jedoch bei mir wiederum nicht der Fall mit OS X 10.6.2:

KeyWest:bin macmark$ cat poc2.c
#include <stdio.h>
#include <stdlib.h>

int
main()
{
char s[]="111.111111...11";

float a=atof(s);
printf("%f",a);
return 0;
}
KeyWest:bin macmark$ gcc -Wall poc2.c -o poc2
KeyWest:bin macmark$ ./poc2
111.111115
KeyWest:bin macmark$ gdb poc2
GNU gdb 6.3.50-20050815 (Apple version gdb-1346) (Fri Sep 18 20:40:51 UTC 2009)

This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries .. done

(gdb) r
Starting program: /Users/macmark/bin/poc2
Reading symbols for shared libraries +. done
111.111115
Program exited normally.

Diese Exploits funktionieren offenbar nicht. Den Grund dafür vermute ich in dieser fälschlichen Annahme:

- --- 1. MacOS X 10.5/10.6 libc/strtod(3) buffer overflow --- The main problem exist in dtoa implementation. MacOS X has the same dtoa as OpenBSD, NetBSD etc. This problem affects not only libc/gdtoa. Affected is also strtod(3) function.

Die Implementation ist eben nicht identisch mit den anderen BSD-Systemen: Die libc von OS X basiert zwar auf der von FreeBSD, aber Apple hat darin 472 Dateien signifikant verändert. Und im Teilbereich dtoa sind immerhin 17 Dateien von Apple gepatcht im Vergleich zu FreeBSD.

Maksymilian Arciemowic ist also vorzuwerfen, daß er Exploits für OS X veröffentlicht, die gar keine sind. Im Gegenteil: Sie zeigen, daß es sauber läuft. Es sieht ganz danach aus, als hätte er die Beispiele überhaupt nicht auf diesem System ausprobiert, sondern einfach aufgrund der falschen Annahme, die Implementationen wäre gleich, die falsche Schlußfolgerung gezogen, auch auf OS X wäre das Verhalten so vorzufinden.

Ferner ist diversen Nachrichten-Magazinen anzukreiden, daß sie solche Berichte völlig ungeprüft übernehmen. Sie sind dankbar für eine tolle Geschichte, die Besucher bringt, und sie machen sich so etwas doch nicht kaputt durch eigene Recherche sofern sie dazu überhaupt in der Lage sind.

Vor sieben Monaten in 2009 hatte Maksymilian Arciemowics bereits schon einmal Exploits für OS X zu der gleichen Stelle veröffentlicht und auch diese funktionierten nur bei den anderen BSDs. Jetzt hat er nochmal nachgelegt und wieder funktioneren seine Exploits nicht auf OS X. Daraufhin berichteten divere kommerzielle Nachrichten-Seiten, daß ein Fehler in OS X seit sieben Monaten nicht behoben wäre. Es ist jedoch völlig unklar, ob das behauptete Problem vorliegt, denn bislang scheiterten alle Exploits, die das zeigen sollten.

Natürlich ist es besser, wenn ein (tatsächlicher) Programmierfehler möglichst schnell behoben wird. Was ich jedoch oft beobachte, ist eine Anti-Apple-Hysterie, die sachlich auf sehr wackeligen Füßen steht. Da wird gerne aus einer Mücke ein Elephant gemacht. Manchmal ist die Mücke auch gar nicht da und nur der Elephant.

In diesem konkreten Fall war es, wenn ich Maksymilian Arciemowic da richtig verstehe, sogar so, daß einige schnelle Aktualisierungen der anderen Hersteller nichts gebracht haben oder neue Fehler einbauten. Auch Mozilla hat fehlerhaft aktualisiert. Und es ist immer noch unklar, ob sich das so auf OS X tatsächlich ausnutzen läßt. Maksymilian Arciemowics Versuche sind ja seit sieben Monaten alle gescheitert. Er hat jedesmal behauptet, OS X wäre auch betroffen, was jedes Mal nicht stimmte. Und das ist einfach nur peinlich! Man sollte seine Exploits auch auf dem Zielsystem getestet haben, wenn man sowas schreibt.

Ich vermute, daß Programmierfehler, die Pufferüberläufe zulassen, noch zu Tausenden in GNU/Linux und in OS X zu finden sind. Und die, die sich tatsächlich gefährlich nutzen lassen, werden oft erst dadurch bekannt, daß sie schon eine Weile in der Praxis ausgenutzt werden.

Bei GNU/Linux sehe ich eine größere Angriffsfläche, weil es nicht wie OS X die Kernel-Erweiterungen bei Bedarf lädt, sondern sie in der Regel in den Kernel compiliert sind. Und damit sind auch potentiell mehr Programmierfehler am laufen.

Was GNU/Linux und OS X gemeinsam ist, ist daß sie keine eklatanten Designfehler haben, die über sieben Jahre nicht gefixt werden können. Und sowas ist real schlimm. Die meisten Leute achten jedoch nicht auf die Qualität der Fehler.

Valid XHTML 1.0!

Besucherzähler


Latest Update: 11. September 2015 at 19:49h (german time)
Link: macmark.de/blog/osx_blog_2010-01.php