Marcello Barnaba (void) <vjt@openssl.it> wrote:
> By the way, even with "Transport setup" -> "Automatic", the software
> doesn't crash nor loops after reading the HTTP payload
An hypotesis is a possible different behaviour depending by the version
of Mac OS, probably bypassable using a modified proof-of-concept or just
not at all.
I have found the following post (in french) which reports a detailed
test made using the latest version of Quicktime on Mac OS X 10.4.11 PPC
and Mac OS X 10.5.1 Intel:
http://forum.macbidouille.com/index.php?act=ST&f=8&t=251685#entry2512134
On both the platforms the code flow has pointed to the return address
specified in the proof-of-concept (on PPC 0x01010119 is just the 0x01
sequence of bytes which was in my PoC before the 'A' sequence).
Anyway this mail is also for pointing out a new
customizable proof-of-concept which I have written yesterday and that
can be used to fully executing code remotely after having passed the
needed valid parameters (my PoC doesn't contain shellcodes, it must be
provided as external file in the classical C/Perl/hexadecimal format
like, for example, those available on The Metasploit Project):
http://aluigi.org/poc/quicktimebof.zip
The success of the exploitation depends by various factors, for example
here using the "QuickTimePlayer.exe rtsp://127.0.0.1/file.mp3" link and
the PoC launched as:
quicktimebof 2134 0x675b29eb shellcode.txt
I have been able to execute code on my Quicktime 7.31.70 (default
options) with a success percentage of almost 100% on both localhost and
LAN, but other ways (like QTL or the manual loading of the URL from the
program for example) could produce different effects and could be
necessary to modify my PoC or the offset of the return address or just a
bit the rtsp URL (moreover its length as noticed from the tests made
here).
The method used in the PoC is very simple:
When the code flow goes on the return address specified by the attacker
the EAX register points to the offset of our error message string
on which starts our custom return address (so, in short, EAX + 4 is our
shellcode).
0x675b29eb is a "CALL EAX" located in QuickTimeStreaming.qtx, so when it
will be executed our code flow will point just to
"eb 29 5b 67 nops shellcode" which is traduced as "JMP +0x29" and will
allow to execute the shellcode located after the 41 bytes skipped by the
JMP.
The 302 redirect used in my PoC has been added because during my tests
gave better results.
Naturally mine is only an idea on which I worked for testing in practice
the effects of the bug here on my system (Windows XP SP2), so anyone can
find better methods and solutions moreover about the "compability".
---
Luigi Auriemma
http://aluigi.org
> By the way, even with "Transport setup" -> "Automatic", the software
> doesn't crash nor loops after reading the HTTP payload
An hypotesis is a possible different behaviour depending by the version
of Mac OS, probably bypassable using a modified proof-of-concept or just
not at all.
I have found the following post (in french) which reports a detailed
test made using the latest version of Quicktime on Mac OS X 10.4.11 PPC
and Mac OS X 10.5.1 Intel:
http://forum.macbidouille.com/index.php?act=ST&f=8&t=251685#entry2512134
On both the platforms the code flow has pointed to the return address
specified in the proof-of-concept (on PPC 0x01010119 is just the 0x01
sequence of bytes which was in my PoC before the 'A' sequence).
Anyway this mail is also for pointing out a new
customizable proof-of-concept which I have written yesterday and that
can be used to fully executing code remotely after having passed the
needed valid parameters (my PoC doesn't contain shellcodes, it must be
provided as external file in the classical C/Perl/hexadecimal format
like, for example, those available on The Metasploit Project):
http://aluigi.org/poc/quicktimebof.zip
The success of the exploitation depends by various factors, for example
here using the "QuickTimePlayer.exe rtsp://127.0.0.1/file.mp3" link and
the PoC launched as:
quicktimebof 2134 0x675b29eb shellcode.txt
I have been able to execute code on my Quicktime 7.31.70 (default
options) with a success percentage of almost 100% on both localhost and
LAN, but other ways (like QTL or the manual loading of the URL from the
program for example) could produce different effects and could be
necessary to modify my PoC or the offset of the return address or just a
bit the rtsp URL (moreover its length as noticed from the tests made
here).
The method used in the PoC is very simple:
When the code flow goes on the return address specified by the attacker
the EAX register points to the offset of our error message string
on which starts our custom return address (so, in short, EAX + 4 is our
shellcode).
0x675b29eb is a "CALL EAX" located in QuickTimeStreaming.qtx, so when it
will be executed our code flow will point just to
"eb 29 5b 67 nops shellcode" which is traduced as "JMP +0x29" and will
allow to execute the shellcode located after the 41 bytes skipped by the
JMP.
The 302 redirect used in my PoC has been added because during my tests
gave better results.
Naturally mine is only an idea on which I worked for testing in practice
the effects of the bug here on my system (Windows XP SP2), so anyone can
find better methods and solutions moreover about the "compability".
---
Luigi Auriemma
http://aluigi.org