exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

ast-chan_skinny.txt

ast-chan_skinny.txt
Posted Oct 21, 2006
Site Security-Assessment.com

The Asterisk Skinny channel driver for Cisco SCCP phones chan_skinny.so) incorrectly validates a length value in the packet header. An integer wrap-around leads to heap overwrite, and arbitrary remote code execution as root.

tags | advisory, remote, arbitrary, root, code execution
systems | cisco
SHA-256 | 375f21639bb208bd239538725658092493aa1588e6038a60e78e34e06d806e2d

ast-chan_skinny.txt

Change Mirror Download
========================================================================
= Asterisk - chan_skinny Remote Unauthenticated Heap Overflow
=
= Vendor Website:
= http://www.asterisk.org
=
= Affected Version:
= All 1.2-branch releases prior to and including 1.2.12.1
= All 1.0-branch releases prior to and including 1.0.12
=
= Not Affected:
= All 1.4-branch beta releases (1.4.0-beta1, 1.4.0-beta2)
=
= Public disclosure on Oct 19, 2006
========================================================================

== Overview ==

Asterisk is "The Opensource PBX", a popular software telephony server.

The Asterisk Skinny channel driver for Cisco SCCP phones chan_skinny.so)
incorrectly validates a length value in the packet header. An integer
wrap-around leads to heap overwrite, and arbitrary remote code execution
as root.

== Details ==

The function 'static int get_input(struct skinnysession *s)' in
chan_skinny.c incorrectly validates a user supplied length in the packet
header. In the code below, four bytes of data are read from the socket,
cast to a signed integer, and assigned to dlen. If dlen is between -1
and -8 then (dlen + 8) will integer wrap to be greater than zero, but
less than sizeof(s->inbuf) for the purposes of this comparison.

Next, dlen + 4 is passed to read() as the maximum number of bytes to
write to s->inbuf+4. Read() takes an unsigned value, so dlen is
interpreted as a very large number. For example, a value of -6 is
interpreted as 0xfffffffa bytes. This instructs read() to write beyond
the allocated 1000 byte length of the buffer s->inbuf.

Code asterisk-1.2.12.1/channels/chan_skinny.c lines 2860-2870
----------------
res = read(s->fd, s->inbuf, 4); // <- integer read from attacker
if (res != 4) {
ast_log(LOG_WARNING, "Skinny Client sent less data than expected.\n");
return -1;
}
dlen = letohl(*(int *)s->inbuf); // <- input 0xfffffffa
// interpreted as signed
if (dlen+8 > sizeof(s->inbuf)) // <- integer wrap to +2

dlen = sizeof(s->inbuf) - 8; // bypasses this check
}
*(int *)s->inbuf = htolel(dlen); // casting just for amusement
res = read(s->fd, s->inbuf+4, dlen+4); /* <- dlen now unsigned again
* permitting read() to write
* up to 0xfffffffa bytes off
* the end of s->inbuf
*/
----------------


== Exploitation ==

An attacker who can connect to the Asterisk server SCCP "Skinny" port
(by default 2000/tcp) can attack the vulnerable function prior to
registering as a configured Skinny phone, permitting pre-authentication
remote compromise.

Once the initial length header value in the packet performs an
integer-wraparound an attacker can overflow off the end of the
malloc()ed input buffer, and into heap space above it. Exploitation is
possible via standard heap-overflow malloc-unlink-macro technique[1] on
glibc versions prior to 2.3.5. On systems with newer glibc, a more
sophisticated exploitation method is necessary due to the improved
validation of malloc's internal heap management linked lists. Brett
Moore's work[2] on bypassing similar restrictions in WinXPSP2 is
instructive.

Our proof-of-concept exploit uses vanilla malloc-unlink() to overwrite a
GOT entry to point execution back into our buffer, and executes
Metasploit port-binding shellcode.

== Solutions ==

- Disable the chan_skinny module if it is not required.
- Firewall port 2000/tcp from untrusted networks.
- Install the vendor supplied upgrades:
1.0-branch: Upgrade to 1.0.12 or later
1.2-branch: Upgrade to 1.2.13 or later

== Credit ==

Discovered and advised to Digium 17th October, 2006 by Adam Boileau of
Security-Assessment.com.

Security-Assessment.com commends Digium on their extremely rapid
response, releasing an updated version within two days of receiving our
vulnerability report.

== References ==

[1] "Advanced Doug Lea's Malloc Exploits" by jp
http://doc.bughunter.net/buffer-overflow/advanced-malloc-exploits.html
[2] "Exploiting Freelist[0] On Windows XP Service Pack 2" by Brett Moore
http://www.security-assessment.com/technical/

== About Security-Assessment.com ==

Security-Assessment.com is Australasia's leading team of Information
Security consultants specialising in providing high quality Information
Security services to clients throughout the Asia Pacific region. Our
clients include some of the largest globally recognised companies in
areas such as finance, telecommunications, broadcasting, legal and
government. Our aim is to provide the very best independent advice and
a high level of technical expertise while creating long and lasting
professional relationships with our clients.

Security-Assessment.com is committed to security research and
development, and its team continues to identify and responsibly publish
vulnerabilities in public and private software vendor's products.
Members of the Security-Assessment.com R&D team are globally recognised
through their release of whitepapers and presentations related to new
security research.

Security-Assessment.com is an Endorsed Commonwealth Government of
Australia supplier and sits on the Australian Government
Attorney-General's Department Critical Infrastructure Project panel.
We are certified by both Visa and MasterCard under their Payment
Card Industry Data Security Standard Programs.

Login or Register to add favorites

File Archive:

March 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Mar 1st
    16 Files
  • 2
    Mar 2nd
    0 Files
  • 3
    Mar 3rd
    0 Files
  • 4
    Mar 4th
    32 Files
  • 5
    Mar 5th
    28 Files
  • 6
    Mar 6th
    42 Files
  • 7
    Mar 7th
    17 Files
  • 8
    Mar 8th
    13 Files
  • 9
    Mar 9th
    0 Files
  • 10
    Mar 10th
    0 Files
  • 11
    Mar 11th
    15 Files
  • 12
    Mar 12th
    19 Files
  • 13
    Mar 13th
    21 Files
  • 14
    Mar 14th
    38 Files
  • 15
    Mar 15th
    15 Files
  • 16
    Mar 16th
    0 Files
  • 17
    Mar 17th
    0 Files
  • 18
    Mar 18th
    10 Files
  • 19
    Mar 19th
    32 Files
  • 20
    Mar 20th
    46 Files
  • 21
    Mar 21st
    16 Files
  • 22
    Mar 22nd
    13 Files
  • 23
    Mar 23rd
    0 Files
  • 24
    Mar 24th
    0 Files
  • 25
    Mar 25th
    12 Files
  • 26
    Mar 26th
    31 Files
  • 27
    Mar 27th
    19 Files
  • 28
    Mar 28th
    42 Files
  • 29
    Mar 29th
    0 Files
  • 30
    Mar 30th
    0 Files
  • 31
    Mar 31st
    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