Re: Buffer-overflow in Quicktime Player 7.3.1.70 Jan 10 2008 09:39PM
Marcello Barnaba (void) (vjt openssl it)

On Jan 10, 2008, at 7:45 PM, Luigi Auriemma wrote:

> For exploiting this vulnerability is only needed that an user follows
> a rtsp:// link, if the port 554 of the server is closed Quicktime will
> automatically change the transport and will try the HTTP protocol on
> port 80, the 404 error message of the server (other error numbers are
> valid too) will be visualized in the LCD-like screen.

Tried on QuickTime 7.3.10 running on OSX 10.5.1, and the player doesn't
try to connect to port 80 if 554 is closed.

Either putting nc to listen on port 554 and making QT connect to rtsp:/
or listening on port 80 and connecting to http:/ does not crash it. So,
yeah, the bug should lie somewhere in the "fallback" that QT employs on
Windows when finding out that the rtsp port is closed.

Best regards!

Marcello
--
pub 1024D/2787EF 723C 7CA3 3C19 2ACE 6E20 9CC1 9956 EB3C 27 87EF

Marcello Barnaba (void) <vjt (at) openssl (dot) it [email concealed]> 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