Mailing List Archive

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/8D2787EF 723C 7CA3 3C19 2ACE 6E20 9CC1 9956 EB3C 8D27 87EF

yea i second that i tested on Vista and it doesnt attempt to redirect to the port 80 there must be another condition that u have specified that allows for redirection

XP redirects just fine.

/str0ke

none@void.gov.com wrote:
> yea i second that i tested on Vista and it doesnt attempt to redirect to the port 80 there must be another condition that u have specified that allows for redirection
>
>

"Marcello Barnaba (void)" <vjt@openssl.it> wrote:
> 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.
> ...
> yea i second that i tested on Vista and it doesnt attempt to redirect
> to the port 80 there must be another condition that u have specified
> that allows for redirection

Uhmmm I imagine you are the same Marcello of yesterday, right?
Who else could be?

Well, first some technical informations.
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").

As already said in my advisory the exploitation happens in the passing
to the http protocol (that's why if you contact port 80 directly nothing
happens).
I don't know if exist better or easier ways to exploit this
vulnerability but in my opinion this one is already excellent.

Now instead we arrive to what leads to "your" problems.
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.

Anyone can test this thing personally for example using a link like
rtsp://aluigi.org/file.mp3 because port 554 and 7070 are filtered there
so Quicktime will give you "disconnected" without trying the "sequence"
(tdimon, api spy softwares and sniffers are your friends).

Naturally what I have said has been tested also on Vista (luckily I have
a friend enough brave to have this so-called OS installed) where I
successfully crashed the client.

Now talking about you, Marcello, the problem you had is just with "your"
same computer/network, probably you have a firewall or something else (a
"condition" as you define it) that simply makes your ports to appear
filtered/timedout and so Quicktime gives up.

The funny thing is that this was also the most logical conclusion, if I
have a broken finger it's normal that everywhere I touch my body I feel
pain so if all the world has successfully tested and confirmed this
vulnerability and you are the only one on the Earth which after changing
OS has the problem the possible causes are not so much...

So, concluding, Quicktime Player 7.3.1.70 IS and remains vulnerable
indipendently by the operating system on which it runs, Windows XP,
Windows Vista, Mac OS X, Y, Z and so on.


BYEZ


---
Luigi Auriemma
http://aluigi.org

Works fine for me:

12:43:42.135629 IP localhost.rtsp > localhost.55957: R 0:0(0) ack 1321728618 win 0
12:43:42.182161 IP localhost.55958 > localhost.arcp: S 4016373806:4016373806(0) win 65535 <mss 16344,nop,wscale 3,nop,nop,timestamp 1071536161 0,sackOK,eol>
12:43:42.182190 IP localhost.arcp > localhost.55958: R 0:0(0) ack 4016373807 win 0
12:43:42.235601 IP localhost.55959 > localhost.http: S 3798466202:3798466202(0) win 65535 <mss 16344,nop,wscale 3,nop,nop,timestamp 1071536162 0,sackOK,eol>
12:43:42.235631 IP localhost.http > localhost.55959: R 0:0(0) ack 3798466203 win 0

tests done on Leopard 10.5.1

> Uhmmm I imagine you are the same Marcello of yesterday, right?
> ...

Rationally my mail didn't want to be a personal attack, unfortunately
yesterday when I wrote it I was a bit stressed due to various things
included the tests I did for solving the doubts raised in the previous
mails.

So please don't consider the first line and the last paragraphs of my
yesterday's mail because non-technical and moreover non-rational.
Right or not, light or weight, nothing on a security mailing list should
be outside the technical matters, moreover if there is no real reason to
reply in a certain way to who simply did a personal test.


---
Luigi Auriemma
http://aluigi.org

On Jan 11, 2008, at 10:14 PM, Luigi Auriemma wrote:

> Now talking about you, Marcello, the problem you had is just with
"your"
> same computer/network, probably you have a firewall or something
else (a
> "condition" as you define it) that simply makes your ports to appear
> filtered/timedout and so Quicktime gives up.

Yeah, you are right. Protocol switching was disabled in my Quicktime
preferences. Sorry about that.. I should have checked before writing
inaccurate statements here.

By the way, even with "Transport setup" -> "Automatic", the software
doesn't crash nor loops after reading the HTTP payload, but I really
don't know why.. It merely sits there, saying "Swiching transports".

Attached a full pcap dump of the session and QuickTime.app's version
plist.

Have fun! :)

Marcello