Core Security Technologies - Corelabs Advisory
http://www.coresecurity.com/corelabs/
Asterisk PBX truncated video miniframe vulnerability
Date Published: 2006-06-09
Last Update: 2006-06-09
Advisory ID: CORE-2006-0330
Bugtraq ID: 18295
CVE Name: CVE-2006-2898
Title: Asterisk PBX truncated video frame vulnerability
Class: Input Validation Error
Remotely Exploitable: Yes
Locally Exploitable: Yes
Advisory URL:
http://www.coresecurity.com/common/showdoc.php?idx=547&idxseccion=10
Vendors contacted:
2006-06-02: Initial notification to vendor
2006-06-02: Vendor response acknowledging notification
2006-06-05: Draft advisory and technical details provided to vendor
2006-06-05: Fixed versions of Asterisk released by vendor
2006-06-06: Asterisk 1.2.9 and 1.0.11 release announcement
Release Mode: COORDINATED RELEASE
*Vulnerability Description:*
Asterisk (http://www.asterisk.org) is an open source software PBX that
supports a wide range of VoIP protocols and equipment. It provides many
IP telephony features including voicemail, interactive voice response,
call queuing, three-way calling, caller ID services, ADSI and more using
SIP, H.323 (as both client and gateway), MGCP, Skinny and the
Asterisk-specific IAX2 protocol.
IAX2 protocol includes support for transmission of video between IAX2
clients that implement such a feature.
A vulnerability found in the Asterisk's handling of IAX2 video frames
could lead to remote compromise of the system running vulnerable
versions of the PBX software through execution of arbitrary code of the
attacker's choosing with the privileges of the Asterisk daemon.
*Vulnerable Packages:*
- Asterisk PBX up to and including v1.2.8
- Asterisk PBX up to and including v1.0.10
Third-party PBX systems that use vulnerable versions of Asterisk such as
Fonality, Asterisk@Home, Switchbox, etc.
*Solution/Vendor Information:*
The following versions of Asterisk PBX are NOT vulnerable to the bug
reported in this advisory
- Asterisk 1.2.9 and above
- Asterisk 1.0.11 and above
These bugfixed versions of Asterisk PBX can be downloaded from
http://www.asterisk.org Users of third-party PBX systems based on
Asterisk should contact their vendor to determine if they are vulnerable
and to obtain a bug fix if necessary.
*Credits:*
Damian Saura, Alejandro Lozanoff, Eduardo Koch, Norberto Kueffner and
Ivan Arce from Core Security Technologies discovered and tested these
vulnerabilities.
We would like to thank Asterisk maintainers Mark Spencer and Kevin
Flemming at Digium.com for responding to our bug report diligently and
for their quickness in addressing the issue and releasing a fix.
*Technical Description - Exploit/Concept Code:*
The Inter-Asterisk Exchange (IAX) protocol provides control and
transmission of streaming media over IP networks. IAX can be used with
any type of streaming media including video and still images but is
targeted primarily at the control of VoIP calls.
The IAX protocol relies on a single UDP port for all communications
(4569/udp). The protocol uses a 15-bit identification number ("call
number") to multiplex several IAX2 streams over the same UDP port. IAX2
messages are called frames. Several basic frame types are described in
the protocol specification draft[1] and defined in the iax2.h header
file of the Asterisk source code package.
An IAX2 full frame uses the 12-byte header described below:
struct ast_iax2_full_hdr {
unsigned short scallno; /*Source call number -- high bit must be 1*/
unsigned short dcallno; /*Destination call number -- high bit is 1 if
retransmission */
unsigned int ts; /* 32-bit timestamp in milliseconds (from 1st
transmission) */
unsigned char oseqno; /* Packet number (outgoing) */
unsigned char iseqno; /* Packet number (next incoming expected) */
unsigned char type; /* Frame type */
unsigned char csub; /* Compressed subclass */
unsigned char iedata[0];
} __attribute__ ((__packed__));
An IAX2 mini-frame, used on established sessions for voice
transmissions, has a 4-byte header:
struct ast_iax2_mini_hdr {
unsigned short callno; /* Source call number -- high bit must be 0,
rest must be non-zero */
unsigned short ts; /* 16-bit Timestamp (high 16 bits from last
ast_iax2_full_hdr) */
/* Frametype implicitly VOICE_FRAME */
/* subclass implicit from last
ast_iax2_full_hdr */
unsigned char data[0];
} __attribute__ ((__packed__));
Video frames are supported using the following 6-byte packet header:
struct ast_iax2_video_hdr {
unsigned short zeros; /* Zeros field -- must be zero */
unsigned short callno; /* Video call number */
unsigned short ts; /* Timestamp and mark if present */
unsigned char data[0];
} __attribute__ ((__packed__));
Asterisk reads IAX2 packets from the network in the socket_read()
function implemented in channels/chan_iax2.c.
The following excerpts are from revision 29849 of the file (included in
the Asterisk 1.2.8 package)
static int socket_read(int *id, int fd, short events, void *cbdata)
{
struct sockaddr_in sin;
int res;
int updatehistory=1;
int new = NEW_PREVENT;
unsigned char buf[4096];
void *ptr;
socklen_t len = sizeof(sin);
...
res = recvfrom(fd, buf, sizeof(buf), 0,(struct sockaddr *) &sin,
&len);
if (res < 0) {
if (errno != ECONNREFUSED)
ast_log(LOG_WARNING, "Error: %s\n",
strerror(errno));
handle_error();
return 1;
}
if(test_losspct) { /* simulate random loss condition */
if( (100.0*rand()/(RAND_MAX+1.0)) < test_losspct)
return 1;
}
[A] if (res < sizeof(struct ast_iax2_mini_hdr)) {
ast_log(LOG_WARNING,
"midget packet received (%d of %d min)\n", res,
(int)sizeof(struct ast_iax2_mini_hdr));
return 1;
}
if ((vh->zeros == 0) && (ntohs(vh->callno) & 0x8000)) {
/* This is a video frame, get call number */
fr->callno = find_callno(ntohs(vh->callno) & ~0x8000,
dcallno, &sin, new,1, fd);
[B] minivid = 1;
} else if (meta->zeros == 0) {
....
At [A] a length check is performed to make sure that the number of bytes
read from the network is not less than those required for a complete a
mini frame header, if that check is passed the packet is further
inspected to determine if it belongs to video-enabled session in [B].
Since the required header length of a IAX2 mini-frame is less than the
header length of a video frame, Asterisk will not reject truncated video
frames of length equal to or greater than 4 bytes (but less than 6-bytes).
Processing of video frames is later done further down the execution flow:
...
} else if (minivid) {
f.frametype = AST_FRAME_VIDEO;
if (iaxs[fr->callno]->videoformat > 0)
f.subclass = iaxs[fr->callno]->videoformat
| (ntohs(vh->ts) & 0x8000 ? 1: 0);
else {
ast_log(LOG_WARNING,
"Received mini frame before first full video frame\n ");
iax2_vnak(fr->callno);
ast_mutex_unlock(&iaxsl[fr->callno]);
return 1;
}
[C] f.datalen = res - sizeof(struct ast_iax2_video_hdr);
if (f.datalen)
f.data = buf + sizeof(struct ast_iax2_video_hdr);
else
f.data = NULL;
...
}
...
[D] iax_frame_wrap(fr, &f)
In [C] the length of video payload is calculated subtracting the size of
video header (number of bytes required in a video header) from the
number of bytes read from the network (return code of the recvfrom()
call). Naturally if a truncated video frame was received the result of
this subtraction will be a negative number and will end up stored in
f.datalen, additionally f.data will end up pointing to memory outside
the boundaries of the packet received.
Later at [D] the iax_frame_wrap() function, implemented in iax2-parser.c
is called:
void iax_frame_wrap(struct iax_frame *fr, struct ast_frame *f)
{
fr->af.frametype = f->frametype;
fr->af.subclass = f->subclass;
fr->af.mallocd = 0; /* Our frame is static relative to the
container */
fr->af.datalen = f->datalen;
fr->af.samples = f->samples;
fr->af.offset = AST_FRIENDLY_OFFSET;
fr->af.src = f->src;
fr->af.delivery.tv_sec = 0;
fr->af.delivery.tv_usec = 0;
fr->af.data = fr->afdata;
if (fr->af.datalen) {
#if __BYTE_ORDER == __LITTLE_ENDIAN
/* We need to byte-swap slinear samples from network
byte order */
if ((fr->af.frametype == AST_FRAME_VOICE) &&
(fr->af.subclass ==AST_FORMAT_SLINEAR)) {
ast_swapcopy_samples(fr->af.data, f->data,
fr->af.samples);
} else
#endif
[E] memcpy(fr->af.data, f->data, fr->af.datalen);
}
}
The memcpy() at [E] will receive a pointer to memory outside of the
packet read from the network as second argument and a negative value as
third argument resulting in an exploitable buffer overflow condition
that could be used by an attacker to execute arbitrary code on the
system running Asterisk.
*Workaround:*
Block inbound packets to port 4569/udp at the perimeter.This workaround
will prevent inter operation of IAX-based VoIP solutions with VoIP
services outside the boundaries of the filtered network. Also, the the
PBX will remain vulnerable to internal attacks from host within the
protected network.
*Additional information and References*
[1] Inter-Asterisk Exchange (IAX) version 2 protocol
(draft-mspencer-iax2-01) http://www.cornfed.com/iax.pdf
*About CoreLabs*
CoreLabs, the research center of Core Security Technologies, is charged
with anticipating the future needs and requirements for information
security technologies. We conduct our research in several important
areas of computer security including system vulnerabilities, cyber
attack planning and simulation, source code auditing, and cryptography.
Our results include problem formalization, identification of
vulnerabilities, novel solutions and prototypes for new technologies.
CoreLabs regularly publishes security advisories, technical papers,
project information and shared software tools for public use at:
http://www.coresecurity.com/corelabs/
*About Core Security Technologies*
Core Security Technologies develops strategic solutions that help
security-conscious organizations worldwide. The company’s flagship
product, CORE IMPACT, is the first automated penetration testing product
for assessing specific information security threats to an organization.
Penetration testing evaluates overall network security and identifies
what resources are exposed. It enables organizations to determine if
current security investments are detecting and preventing attacks. Core
augments its leading technology solution with world-class security
consulting services, including penetration testing, software security
auditing and related training.
Based in Boston, MA. and Buenos Aires, Argentina, Core Security
Technologies can be reached at 617-399-6980 or on the Web at
http://www.coresecurity.com.
*DISCLAIMER:*
The contents of this advisory are copyright (c) 2006 CORE Security
Technologies and (c) 2006 Corelabs, and may be distributed freely
provided that no fee is charged for this distribution and proper credit
is given.
$Id: Asterisk-minivid-advisory.txt,v 1.4 2006/06/09 20:12:00 iarce Exp $