Marcello Barnaba (void) <vjt@xxxxxxxxxx> 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