glibc fnmatch-Schwachstelle: Wie man die Schwachstelle aussetzt?

Question

Ich muss eine Schwachstelle auf einem unserer 64-Bit-Systeme validieren, auf denen glibc-2.9 läuft.

http://scarybeastsecurity.blogspot.in/2011/02/i-got-accidental-code-execution-via.html

Der obige Link gibt ein Skript, das als eine magische Zahl scheinbar führt zu beliebiger Code zur Ausführung weitergegeben. Aber als ich es auf meinem System versuchte, scheint nichts zu passieren. Mache ich etwas falsch? Stürzt das System ab, wenn die Sicherheitsanfälligkeit besteht? Wie erkenne ich, ob es sich um eine versehentliche Codeausführung handelt?

Answer 1

Wenn Sie auf einer 64-Bit-Maschine auf das Problem stoßen, müssen Sie den ursprünglichen Code nachahmen, aber eine Nummer angeben, die den Stapel auf einer 64-Bit-Maschine umschließt. Die ursprüngliche Zahl vorgesehen war:

$ bc 
z=1073741796 
z+28 
1073741824 
(z+28)*4 
4294967296 
2^32 
4294967296 
quit 
$ 

also eine Möglichkeit, die Anzahl der Eingangs beschreibt, ist (ULONG_MAX - 112)/4.

Die analoge Nummer für eine 64-Bit-Maschine ist, 4611686018427387876:

$ bc 
x=2^64 
x 
18446744073709551616 
y=x/4 
y 
4611686018427387904 
y-28 
4611686018427387876 
quit 
$ 

jedoch eine Chance, dieses Arbeits stehen, würden Sie den gemeldeten Code ändern müssen, um ähnliche strtroull() oder etwas zu verwenden; atoi() ist normalerweise auf 32-Bit-Ganzzahlen begrenzt und würde bei den obigen 64-Bit-Zahlen nicht verwendet werden. Der Code enthält außerdem:

num_as = atoi(argv[1]); 
if (num_as < 5) { 
    errx(1, "Need 5."); 
} 
p = malloc(num_as); 

Wo num_as ist ein size_t und p ein char * ist. Also, Sie müssten malloc() eine gigantische Menge an Platz (fast 4 EiB) haben. Die meisten Leute haben nicht genügend virtuellen Speicher auf ihren Rechnern, auch nicht mit Festplattenspeicher für die Unterstützung, um das zu tun. Nun, vielleicht, nur vielleicht, würde Linux es Ihnen erlauben, zu viel zu committen (und den OOM Killer später hereinfallen zu lassen), aber die malloc() würde eher scheitern.

Es gab andere Funktionen, die relevant waren und 32-Bit-Systeme so beeinflussen, dass sie 64-Bit-Systeme (noch) nicht beeinflussen können.

Wenn Sie eine Chance haben, es auf einem 64-Bit-Gerät zu reproduzieren, müssen Sie wahrscheinlich eine 32-Bit-Kompilierung durchführen. Dann, wenn der Wind hinter Ihnen ist und Sie entsprechend alte Versionen der relevanten Software haben, können Sie sie vielleicht reproduzieren.

Answer 2

Wenn Sie auf einem 64-Bit-Computer ausgeführt werden, gelten die ursprünglichen Umstände des Fehlers nicht. Wie Sie in Chris Blog sehen können, verwendet er ein 32-Bit Ubuntu 9.04 System. Der Exploit beruht darauf, den Stapelzeiger dazu zu bringen, den 32-Bit-Adressraum zu umbrechen, was zu einer Stapelkorruption führt.

Ich habe es auf einem 64-Bit-System mit Glibc 2.5 versucht, aber sah Malloc() Fehler statt Abstürze.

$ ./a.out 3000000000 
a.out: malloc() failed. 

Sie haben gefragt, wie Sie die Ausführung von versehentlichem Code identifizieren können. mit dem Spielzeugprogramm hier, das keinen Exploit/Payload enthält, würden wir erwarten, entweder einen SIGSEGV, SIGILL oder SIGBUS zu sehen, da die CPU versuchte, Junk-Teile des Stapels "auszuführen", was sich als der jeweilige Fehler zeigte Nachricht von der Shell.