what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

fengulo.txt

fengulo.txt
Posted Dec 29, 2007
Authored by Luigi Auriemma | Site aluigi.org

Feng versions 0.1.15 and below suffer from buffer overflow and denial of service vulnerabilities.

tags | advisory, denial of service, overflow, vulnerability
SHA-256 | 6d66f08551e8a361293d57f93f34f6363a461dfe29986834e42b8b0d57bb9541

fengulo.txt

Change Mirror Download

#######################################################################

Luigi Auriemma

Application: Feng
http://live.polito.it/documentation/feng
Versions: <= 0.1.15
Platforms: *nix
Bugs: A] first buffer-overflow in RTSP_valid_response_msg
B] second buffer-overflow in RTSP_valid_response_msg
C] crash in RTSP_remove_msg
D] NULL pointer in parse_transport_header
E] NULL pointer in parse_play_time_range
F] NULL pointer in log_user_agent
G] NULL pointer in Netembryo 0.0.4
Exploitation: remote
Date: 27 Dec 2007
Author: Luigi Auriemma
e-mail: aluigi@autistici.org
web: aluigi.org


#######################################################################


1) Introduction
2) Bugs
3) The Code
4) Fix


#######################################################################

===============
1) Introduction
===============


Feng is an open source RTSP/RTP streaming server written by the italian
team of the Politecnico di Torino University for the LScube project.


#######################################################################

=======
2) Bugs
=======

---------------------------------------------------
A] first buffer-overflow in RTSP_valid_response_msg
---------------------------------------------------

A buffer-overflow vulnerability is exploitable through a stack buffer
of 15 bytes called trash used as destination by sscanf without the
needed size limits.

>From rtsp/RTSP_state_machine.c:

int RTSP_valid_response_msg(unsigned short *status, char *msg, RTSP_buffer * rtsp)
// This routine is from BP.
{
char ver[32], trash[15];
unsigned int stat;
unsigned int seq;
int pcnt; /* parameter count */

*ver = *msg = '\0';
/* assuming "stat" may not be zero (probably faulty) */
stat = 0;

pcnt =
sscanf(rtsp->in_buffer, " %31s %u %s %s %u\n%255s ", ver, &stat,
trash, trash, &seq, msg);
...


----------------------------------------------------
B] second buffer-overflow in RTSP_valid_response_msg
----------------------------------------------------

A buffer-overflow vulnerability is exploitable through a stack buffer
of 100 bytes called msg used as destination by sscanf limited to 255
bytes in the function RTSP_valid_response_msg.

>From rtsp/RTSP_state_machine.c:

int RTSP_handler(RTSP_buffer * rtsp)
{
unsigned short status;
char msg[100];
...
op = RTSP_valid_response_msg(&status, msg, rtsp);
...

int RTSP_valid_response_msg(unsigned short *status, char *msg, RTSP_buffer * rtsp)
...
sscanf(rtsp->in_buffer, " %31s %u %s %s %u\n%255s ", ver, &stat,
trash, trash, &seq, msg);
...


---------------------------
C] crash in RTSP_remove_msg
---------------------------

An integer overflow is exploitable through the RTP packets.
Using a 16 bit size value of 0xffff is possible to force the server to
move 4294967293 bytes in the destination buffer:

RTSP_BUFFERSIZE = 65536
len = 65539 (4 of hdrlen + 0xffff)
result = -3

>From rtsp/RTSP_lowlevel.c:

void RTSP_remove_msg(int len, RTSP_buffer * rtsp)
{
rtsp->in_size -= len;
if (rtsp->in_size && len) { /* discard the message from the in_buffer. */
memmove(rtsp->in_buffer, &(rtsp->in_buffer[len]),
RTSP_BUFFERSIZE - len);
memset(&(rtsp->in_buffer[len]), 0, RTSP_BUFFERSIZE - len);
}
}


-----------------------------------------
D] NULL pointer in parse_transport_header
-----------------------------------------

>From rtsp/RTSP_setup.c:

static RTSP_Error parse_transport_header(RTSP_buffer * rtsp,
...
p = strstr(p, "=");
sscanf(p + 1, "%d", &(cli_ports.RTP));
p = strstr(p, "-");
sscanf(p + 1, "%d", &(cli_ports.RTCP));
...
p = strstr(p, "=");
sscanf(p + 1, "%d", &rtp_ch);
...
p = strstr(p, "=");
sscanf(p + 1, "%d", &rtp_ch);
...


----------------------------------------
E] NULL pointer in parse_play_time_range
----------------------------------------

>From rtsp/RTSP_Play:

static RTSP_Error parse_play_time_range(RTSP_buffer * rtsp, play_args * args)
...
q = strchr(q, '=');
if (get_utc(&(args->playback_time), q + 1) != ERR_NOERROR) {
...


---------------------------------
F] NULL pointer in log_user_agent
---------------------------------

The log_user_agent function uses an unchecked strstr for finding the
end of the User-Agent value (a line field), but the server can handle
also carriage-return chars allowing an attacker to crash it using only
0x0d chars in his request.

>From rtsp/RTSP_utils.c:

void log_user_agent(RTSP_buffer * rtsp)
{
char * p;

if ((p = strstr(rtsp->in_buffer, HDR_USER_AGENT)) != NULL) {
char cut[strlen(p)];
strcpy(cut, p);
p = strstr(cut, "\n");
cut[strlen(cut) - strlen(p) - 1] = '\0';
...


----------------------------------
G] NULL pointer in Netembryo 0.0.4
----------------------------------

Although this vulnerability affects another software of the LScube
project I have preferred to include it here since only when used with
Feng this bug can be considered a security bug (Netembryo in fact is
used also in libnemesi which is a client-side library).

The usage of the ':' char after the backslash allows an attacker to
crash the server on which is used the Url_init() function of the
Netembryo library.
In short when an urlname like /: is used the port_begin and path_begin
pointers will point to the same location bypassing the check
"port_begin > path_begin", then the function will try to allocate
4294967294 bytes (-2 resulted by (size_t)(path_begin - port_begin - 1))
for url->port which will fail and so the resulted NULL pointer will be
used as destination in the subsequent strncpy.

>From utils/url.c:

int Url_init(Url * url, char * urlname)
{
...
path_begin = strstr(hostname_begin, "/");
if (path_begin == NULL) {
path_len = 0;
}
else {
++path_begin;
...
port_begin = strstr(hostname_begin, ":");
if ((port_begin == NULL) || ((port_begin > path_begin) && (path_begin != NULL))) {
...
if (port_len) {
url->port = (char*)malloc(port_len+1);
strncpy(url->port, port_begin, port_len);
url->port[port_len] = '\0';
}
...


#######################################################################

===========
3) The Code
===========


http://aluigi.org/poc/fengulo.zip

nc SERVER 554 -v -v < bof1.txt
...
nc SERVER 554 -v -v < netembry0.txt


#######################################################################

======
4) Fix
======


The bugs will be fixed in the next days.


#######################################################################


---
Luigi Auriemma
http://aluigi.org
Login or Register to add favorites

File Archive:

April 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Apr 1st
    10 Files
  • 2
    Apr 2nd
    26 Files
  • 3
    Apr 3rd
    40 Files
  • 4
    Apr 4th
    6 Files
  • 5
    Apr 5th
    26 Files
  • 6
    Apr 6th
    0 Files
  • 7
    Apr 7th
    0 Files
  • 8
    Apr 8th
    22 Files
  • 9
    Apr 9th
    14 Files
  • 10
    Apr 10th
    10 Files
  • 11
    Apr 11th
    13 Files
  • 12
    Apr 12th
    14 Files
  • 13
    Apr 13th
    0 Files
  • 14
    Apr 14th
    0 Files
  • 15
    Apr 15th
    30 Files
  • 16
    Apr 16th
    10 Files
  • 17
    Apr 17th
    22 Files
  • 18
    Apr 18th
    45 Files
  • 19
    Apr 19th
    0 Files
  • 20
    Apr 20th
    0 Files
  • 21
    Apr 21st
    0 Files
  • 22
    Apr 22nd
    0 Files
  • 23
    Apr 23rd
    0 Files
  • 24
    Apr 24th
    0 Files
  • 25
    Apr 25th
    0 Files
  • 26
    Apr 26th
    0 Files
  • 27
    Apr 27th
    0 Files
  • 28
    Apr 28th
    0 Files
  • 29
    Apr 29th
    0 Files
  • 30
    Apr 30th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close