bugtraq - Re: Buffer-overflow in Quicktime Player 7.3.1.70

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20080111221449.71fa4bbd.aluigi@autistici.org>
Date: Fri, 11 Jan 2008 22:14:49 +0100
From: Luigi Auriemma <aluigi@...istici.org>
To: "Marcello Barnaba (void)" <vjt@...nssl.it>
Cc: bugtraq@...urityfocus.com, bugs@...uritytracker.com,
	news@...uriteam.com, full-disclosure@...ts.grok.org.uk,
	vuln@...unia.com, packet@...ketstormsecurity.org
Subject: Re: Buffer-overflow in Quicktime Player 7.3.1.70

"Marcello Barnaba (void)" <vjt@...nssl.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