[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Buffer-overflow in Quicktime Player 126.96.36.199
"Marcello Barnaba (void)" <vjt@xxxxxxxxxx> 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
- 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
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
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 188.8.131.52 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.