Asterisk PBX truncated video frame 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
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 release announced
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 bug-fixed 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 dilligently 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 transmition, 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
",
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)
", 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 an 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
");
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 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 $