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 for Android: free password hash cracker in your pocket

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

Message-Id: <57444AA7-E40C-4C49-9C83-8B72E8165950@openssl.it>
Date: Thu, 10 Jan 2008 22:39:10 +0100
From: "Marcello Barnaba (void)" <vjt@...nssl.it>
To: Luigi Auriemma <aluigi@...istici.org>
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

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