#######################################################################

                             Luigi Auriemma

Application:  Quicktime Player
              http://www.apple.com/quicktime
Versions:     <= 7.3.1.70
Platforms:    Windows and Mac
Bug:          buffer-overflow
Exploitation: remote
Date:         10 Jan 2008
Thanx to:     swirl for the help during the re-testing of the bug
Author:       Luigi Auriemma
              e-mail: aluigi@autistici.org
              web:    aluigi.org


#######################################################################


1) Introduction
2) Bug
3) The Code
4) Fix


#######################################################################

===============
1) Introduction
===============


Quicktime is a well known media player developed by Apple.


#######################################################################

======
2) Bug
======


The problem is a buffer-overflow which happens during the handling of
the HTTP error message and its visualization in the LCD-like screen
which contains info about the status of the connection.

The copying instruction is visible starting at offset 0x6761d559, the
return address can be overwritten completely by the 4 bytes at offset
1926 of the error message, only NULL and carriage-return/line-feed
chars are not allowed to use and after the exploitation EAX will point
to the same offset where is located the data which overwrote the return
address (so EAX + 4 points to the shellcode).

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.

Note: this "protocol switching" thing is only the first way I have
found for testing the bug so I can't exclude (for the moment) the
possibility of reaching the vulnerable code using better and easier
ways.

In short this feature (enabled by default, watch "Transport setup")
acts in the following way:
When the rtsp url is called (and no custom port has been specified)
Quicktime performs 3 types of consecutive connections, something like
a scanning:
- port 554 (rtsp) using the rtsp protocol (DESCRIBE)
- port 7070 (pnm) using the rtsp protocol (DESCRIBE)
- port 80 (http) using the http protocol (GET)

Everything can be seen at offset 0x675A32C9 of QuickTimeStreaming.qtx
where ECX has the value of 1, 2 and 3 relatively to the previous
"stages" (4 means "give up").

If the connection times out Quicktime automatically considers the
remote host as unreacheable and will no longer continue the "protocol
switching".
For example if port 554 is closed it passes to port 7070, and if port
7070 is filtered (timeout) Quicktime gives up and doesn't check port
80.


#######################################################################

===========
3) The Code
===========


http://aluigi.org/poc/quicktimebof.zip


#######################################################################

======
4) Fix
======


No fix

UPDATE 16 Jan 2008
The new version 7.4.0.91 doesn't fix the bug but code execution is not
confimed.


#######################################################################