Bug#841224: MediaTomb Multiple Remote Vulnerabilities

Tue Oct 18 16:17:06 UTC 2016

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 security at 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 at 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 at entry=2,
fmt=fmt at entry=0x7ffff5022c7f "*** %s ***: %s terminated\n") at
../sysdeps/posix/libc_fatal.c:175
#3  0x00007ffff4fac89c in __GI___fortify_fail (msg=<optimized out>,
msg at 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 at entry=0x7fffd0001280
"ssdp:uuid:schemas:device:", 'a' <repeats 175 times>...,
Evt=Evt at 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 at entry=0x7fffdf7fd770) at ../upnp/src/ssdp/ssdp_server.c:634
#9  0x0000000000524e0a in ssdp_handle_device_request
(hmsg=hmsg at entry=0x7fffd80008c0,
dest_addr=dest_addr at 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 at 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 at entry=2,
fmt=fmt at entry=0x7ffff5022c7f "*** %s ***: %s terminated\n") at
../sysdeps/posix/libc_fatal.c:175
#3  0x00007ffff4fac89c in __GI___fortify_fail (msg=<optimized out>,
msg at 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 at entry=0x7fffb4001190 "uuid:", 'a'
<repeats 195 times>..., Evt=Evt at 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 at entry=0x7fffbfffe770) at
../upnp/src/ssdp/ssdp_server.c:634
#9  0x0000000000524e0a in ssdp_handle_device_request
(hmsg=hmsg at entry=0x7fffd80011a0,
dest_addr=dest_addr at 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 at 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 at entry=0x7fffbfffec10, isQuery=isQuery at entry=0,
actionDoc=actionDoc at entry=0x7fffb4001730,
device_udn=device_udn at entry=0x7fffbfffe8cc "",
    service_id=service_id at entry=0x7fffbfffe9cc "\377\177",
callback=callback at entry=0x7fffbfffe6e0, cookie=0x7fffbfffe6e8) at
../upnp/src/soap/soap_device.c:669
#3  0x00000000005203ad in handle_invoke_action
(info=info at entry=0x7fffbfffec00, request=request at 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 at 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 at 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 at entry=0x7ffff50213f9 "malloc.c", line=line at entry=2395,
function=function at entry=0x7ffff5025180 <__func__.11527> "sysmalloc") at
malloc.c:300
#3  0x00007ffff4f14ca6 in sysmalloc (nb=nb at entry=80,
av=av at entry=0x7fffd4000020) at malloc.c:2392
#4  0x00007ffff4f15feb in _int_malloc (av=av at entry=0x7fffd4000020,
bytes=bytes at entry=65) at malloc.c:3828
#5  0x00007ffff4f169f0 in _int_realloc (av=av at entry=0x7fffd4000020,
oldp=oldp at entry=0x7fffd4000b00, oldsize=oldsize at entry=48,
nb=nb at 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 at 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 at entry=0x7fffde7fb9c0, http_major_version=1,
http_minor_version=1, fmt=0x53dde2 "SNsscscAc", fmt at entry=0x53dde0
"RDSNsscscAc")
    at ../upnp/src/genlib/net/http/httpreadwrite.c:2004
#10 0x0000000000513973 in respond_ok (info=info at entry=0x7fffde7fbc00,
time_out=20, sub=sub at entry=0x7fffd4000aa0,
request=request at 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 at ubuntu:~ $ cat /usr/share/mediatomb/web/danger_zone
Better call Kenny Loggins
albino-lobster at ubuntu:~ $