Package: mediatomb Version: 0.12.1-47 Severity: critical
This was discovered on Ubuntu and reported to them. Ubuntu replied that the package is inherited from Debian "which means it isn't supported by the Ubuntu Security Team." We notified secur...@debian.org who suggested we open a ticket. If any of our PoCs are required, we will share via email with Debian or any other Linux vendor impacted, but not make them public in a tracker. -- While testing a new NASL detection script, we found it was causing a crash in MediaTomb. Specifically, there is a NULL pointer dereference at in the function check_soap_body() in soap_device.c (line 470). We went to see if this had been patched in libupnp and found that it had been patched eight years ago (https://sourceforge.net/p/pupnp/code/ci/2c094ee8ea01259967f82513296b031f718603fd/). Given that MediaTomb is still being distributed by Ubuntu and more than 1,000 instances are visible via Shodan (https://www.shodan.io/search?query=MediaTomb), we will make a best-effort to quickly flag some of the vulnerabilities that we know have been fixed in libupnp and still exist in MediaTomb. All of the below have been tested on Ubuntu 16.04 x64 Desktop using mediatomb-dbg. We believe them to be vulnerable in Debian 8.6 (jesse) as well. CVE-2012-5958, CVE-2012-5959, CVE-2012-5960 Humorously? Fedora actually has this in their bug tracker for MediaTomb along with the other 2012 stack overflows, all unfixed (https://bugzilla.redhat.com/show_bug.cgi?id=906045), despite an upstream patch being available (https://sourceforge.net/p/pupnp/code/ci/2bb79879b77dd215a26c92d1348adf2ae406dfd8/). We've written a PoC cleverly named "cve-2012-5958.py" that triggers the issue, producing the following stack trace: (gdb) bt #0 0x00007ffff4ec9418 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 #1 0x00007ffff4ecb01a in __GI_abort () at abort.c:89 #2 0x00007ffff4f0b72a in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0x7ffff5022c7f "*** %s ***: %s terminated\n") at ../sysdeps/posix/libc_fatal.c:175 #3 0x00007ffff4fac89c in __GI___fortify_fail (msg=<optimized out>, msg@entry=0x7ffff5022c10 "buffer overflow detected") at fortify_fail.c:37 #4 0x00007ffff4faa8a0 in __GI___chk_fail () at chk_fail.c:28 #5 0x00007ffff4fa9d49 in __strncpy_chk (s1=<optimized out>, s2=<optimized out>, n=<optimized out>, s1len=<optimized out>) at strncpy_chk.c:26 #6 0x000000000052110a in strncpy (__len=421, __src=<optimized out>, __dest=0x7fffdf7fd590 "4") at /usr/include/x86_64-linux-gnu/bits/string3.h:126 #7 unique_service_name (cmd=cmd@entry=0x7fffd0001280 "ssdp:uuid:schemas:device:", 'a' <repeats 175 times>..., Evt=Evt@entry=0x7fffdf7fd770) at ../upnp/src/ssdp/ssdp_server.c:532 #8 0x0000000000521392 in ssdp_request_type (cmd=0x7fffd0001280 "ssdp:uuid:schemas:device:", 'a' <repeats 175 times>..., Evt=Evt@entry=0x7fffdf7fd770) at ../upnp/src/ssdp/ssdp_server.c:634 #9 0x0000000000524e0a in ssdp_handle_device_request (hmsg=hmsg@entry=0x7fffd80008c0, dest_addr=dest_addr@entry=0x7fffd8000a38) at ../upnp/src/ssdp/ssdp_device.c:157 #10 0x00000000005209cd in ssdp_event_handler_thread (the_data=0x7fffd80008c0) at ../upnp/src/ssdp/ssdp_server.c:797 #11 0x0000000000523373 in WorkerThread (arg=0x798d00 <gRecvThreadPool>) at ../threadutil/src/ThreadPool.c:594 #12 0x00007ffff70d76fa in start_thread (arg=0x7fffdf7fe700) at pthread_create.c:333 #13 0x00007ffff4f9ab5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 We’ve also written a PoC named "cve-2012-5959.py" (consistency is key) that triggers the issue, producing the following stack trace: (gdb) bt #0 0x00007ffff4ec9418 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 #1 0x00007ffff4ecb01a in __GI_abort () at abort.c:89 #2 0x00007ffff4f0b72a in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0x7ffff5022c7f "*** %s ***: %s terminated\n") at ../sysdeps/posix/libc_fatal.c:175 #3 0x00007ffff4fac89c in __GI___fortify_fail (msg=<optimized out>, msg@entry=0x7ffff5022c10 "buffer overflow detected") at fortify_fail.c:37 #4 0x00007ffff4faa8a0 in __GI___chk_fail () at chk_fail.c:28 #5 0x00007ffff4fa9d49 in __strncpy_chk (s1=<optimized out>, s2=<optimized out>, n=<optimized out>, s1len=<optimized out>) at strncpy_chk.c:26 #6 0x00000000005211a1 in strncpy (__len=404, __src=0x7fffb4001190 "uuid:", 'a' <repeats 195 times>..., __dest=0x7fffbfffe784 "") at /usr/include/x86_64-linux-gnu/bits/string3.h:126 #7 unique_service_name (cmd=cmd@entry=0x7fffb4001190 "uuid:", 'a' <repeats 195 times>..., Evt=Evt@entry=0x7fffbfffe770) at ../upnp/src/ssdp/ssdp_server.c:544 #8 0x0000000000521392 in ssdp_request_type (cmd=0x7fffb4001190 "uuid:", 'a' <repeats 195 times>..., Evt=Evt@entry=0x7fffbfffe770) at ../upnp/src/ssdp/ssdp_server.c:634 #9 0x0000000000524e0a in ssdp_handle_device_request (hmsg=hmsg@entry=0x7fffd80011a0, dest_addr=dest_addr@entry=0x7fffd8001318) at ../upnp/src/ssdp/ssdp_device.c:157 #10 0x00000000005209cd in ssdp_event_handler_thread (the_data=0x7fffd80011a0) at ../upnp/src/ssdp/ssdp_server.c:797 #11 0x0000000000523373 in WorkerThread (arg=0x798d00 <gRecvThreadPool>) at ../threadutil/src/ThreadPool.c:594 #12 0x00007ffff70d76fa in start_thread (arg=0x7fffbffff700) at pthread_create.c:333 #13 0x00007ffff4f9ab5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Bug 1948586 A null pointer dereference can be triggered via an HTTP POST with malformed SOAP data, with an upstream patch available (https://sourceforge.net/p/pupnp/code/ci/2c094ee8ea01259967f82513296b031f718603fd/). We wrote a PoC cleverly called bug_1948586.py that triggers the issue in MediaTomb and produces the following stack trace below. Note that the old SourceForge bug tracker that used 7-digit IDs was deprecated, and it does not appear that those tickets were preserved, at least not publicly. As such, we only have a commit that references the old bug ID, and the commit details itself. (gdb) bt #0 __strcmp_sse2_unaligned () at ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:204 #1 0x000000000051fc81 in check_soap_body (doc=doc@entry=0x7fffb4001730, urn=0x7fefd0 "urn:schemas-upnp-org:service:ContentDirectory:1", actionName=0x7fffb40017a0 "Browse") at ../upnp/src/soap/soap_device.c:470 #2 0x000000000051fe36 in get_device_info (request=request@entry=0x7fffbfffec10, isQuery=isQuery@entry=0, actionDoc=actionDoc@entry=0x7fffb4001730, device_udn=device_udn@entry=0x7fffbfffe8cc "", service_id=service_id@entry=0x7fffbfffe9cc "\377\177", callback=callback@entry=0x7fffbfffe6e0, cookie=0x7fffbfffe6e8) at ../upnp/src/soap/soap_device.c:669 #3 0x00000000005203ad in handle_invoke_action (info=info@entry=0x7fffbfffec00, request=request@entry=0x7fffbfffec10, action_name=..., xml_doc=0x7fffb4001730) at ../upnp/src/soap/soap_device.c:974 #4 0x000000000052092a in soap_device_callback (parser=<optimized out>, request=0x7fffbfffec10, info=0x7fffbfffec00) at ../upnp/src/soap/soap_device.c:1082 #5 0x0000000000515a72 in dispatch_request (hparser=0x7fffbfffec10, info=0x7fffbfffec00) at ../upnp/src/genlib/miniserver/miniserver.c:236 #6 handle_request (args=0x7fffd8001390) at ../upnp/src/genlib/miniserver/miniserver.c:339 #7 0x0000000000523373 in WorkerThread (arg=0x798d00 <gRecvThreadPool>) at ../threadutil/src/ThreadPool.c:594 #8 0x00007ffff70d76fa in start_thread (arg=0x7fffbffff700) at pthread_create.c:333 #9 0x00007ffff4f9ab5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Bug 133 (https://sourceforge.net/p/pupnp/bugs/133/) (VulnDB 143911, no CVE) A heap overflow can be triggered when providing specifically crafted callback parameters. Currently, there does not seem to be a patch for this issue. We wrote a PoC cleverly called bug_133.py that triggers the issue in MediaTomb, generating the following stack trace: (gdb) bt #0 0x00007ffff4ec9418 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 #1 0x00007ffff4ecb01a in __GI_abort () at abort.c:89 #2 0x00007ffff4f11418 in __malloc_assert ( assertion=assertion@entry=0x7ffff5024968 "(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)", file=file@entry=0x7ffff50213f9 "malloc.c", line=line@entry=2395, function=function@entry=0x7ffff5025180 <__func__.11527> "sysmalloc") at malloc.c:300 #3 0x00007ffff4f14ca6 in sysmalloc (nb=nb@entry=80, av=av@entry=0x7fffd4000020) at malloc.c:2392 #4 0x00007ffff4f15feb in _int_malloc (av=av@entry=0x7fffd4000020, bytes=bytes@entry=65) at malloc.c:3828 #5 0x00007ffff4f169f0 in _int_realloc (av=av@entry=0x7fffd4000020, oldp=oldp@entry=0x7fffd4000b00, oldsize=oldsize@entry=48, nb=nb@entry=80) at malloc.c:4305 #6 0x00007ffff4f17db9 in __GI___libc_realloc (oldmem=0x7fffd4000b10, bytes=68) at malloc.c:3046 #7 0x000000000051f617 in membuffer_set_size (m=m@entry=0x7fffde7fb9c0, new_length=54) at ../upnp/src/genlib/util/membuffer.c:234 #8 0x000000000051f7bb in membuffer_insert (m=0x7fffde7fb9c0, buf=0x7fffde7fb830, buf_len=37, index=17) at ../upnp/src/genlib/util/membuffer.c:454 #9 0x0000000000519ad1 in http_MakeMessage (buf=buf@entry=0x7fffde7fb9c0, http_major_version=1, http_minor_version=1, fmt=0x53dde2 "SNsscscAc", fmt@entry=0x53dde0 "RDSNsscscAc") at ../upnp/src/genlib/net/http/httpreadwrite.c:2004 #10 0x0000000000513973 in respond_ok (info=info@entry=0x7fffde7fbc00, time_out=20, sub=sub@entry=0x7fffd4000aa0, request=request@entry=0x7fffde7fbc10) at ../upnp/src/gena/gena_device.c:1189 #11 0x00000000005152d2 in gena_process_subscription_request (info=0x7fffde7fbc00, request=0x7fffde7fbc10) at ../upnp/src/gena/gena_device.c:1462 #12 0x0000000000515a72 in dispatch_request (hparser=0x7fffde7fbc10, info=0x7fffde7fbc00) at ../upnp/src/genlib/miniserver/miniserver.c:236 #13 handle_request (args=0x7fffd8002040) at ../upnp/src/genlib/miniserver/miniserver.c:339 #14 0x0000000000523373 in WorkerThread (arg=0x798d00 <gRecvThreadPool>) at ../threadutil/src/ThreadPool.c:594 #15 0x00007ffff70d76fa in start_thread (arg=0x7fffde7fc700) at pthread_create.c:333 #16 0x00007ffff4f9ab5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:1 CVE-2016-6255 This allows a remote unauthenticated attacker create arbitrary files in the WebRoot simply by sending an HTTP POST request. Note that Ubuntu's mediatomb installation must have write permission to the WebRoot directory. This issue has been patched by c91a8a3 (https://sourceforge.net/p/pupnp/code/ci/c91a8a3903367e1163765b73eb4d43be7d7927fa/) and 66e43a2 (https://sourceforge.net/p/pupnp/code/ci/66e43a28d27fee95d270d2b8106d8a099c14f334/). We wrote a PoC cleverly called "cve-2016-6255.py" that when used like so: $ ./cve-2016-6255.py http://192.168.1.217:49153/danger_zone Will result in a file being created. This can be seen in the default Ubuntu install, with the following sorcery: albino-lobster@ubuntu:~ $ cat /usr/share/mediatomb/web/danger_zone Better call Kenny Loggins albino-lobster@ubuntu:~ $
