MediaTomb is an open source UPnP MediaServer. For various reasons, MediaTomb has seen wide deployment over the years. However, the project appears to have been abandoned by the creators as the primary website hasn’t seen an update since 2010 and the SorceForge SVN repository hasn’t seen a commit since 2014. However, that has not slowed the apparent love and integration of MediaTomb. The SourceForge page claims over 200 downloads this week, the discussion forums have been written to fairly recently, and Stack Overflow still gets questions.
This is probably because
Ubuntu has continued offering it as a package. However, they
haven’t done a lot to the code themselves it appears, even though
open bugs exists. For the purposes of this write up, we will be referring to the Ubuntu package since they appear to be hosting/distributing more than anyone else. That said, other Linux distributions may have their own forks of MediaTomb and be vulnerable to the same issues below, such as Debian as we later confirmed.
About the MediaTomb Code
Anyone that has had the distinct displeasure of reading the Portable Universal Plug and Play SDK (libupnp) source code would immediately recognize that MediaTomb is built on a fork of libupnp. Indeed, some quick investigation into this confirmed that MediaTomb uses their own libUPnP with "various custom patches and extensions". Notice, that the Fedora mediatomb package maintainer even links to a libupnp CERT VU. We can only assume that libupnp vulnerabilities don’t apply, right?
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.
Given that MediaTomb is still being distributed by Ubuntu and more than 1,000 instances are visible via Shodan, 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.
Fedora actually has this in their bug tracker for MediaTomb along with the other 2012 stack overflows, all unfixed, despite an upstream patch being available.
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=, 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=, s2=, n=, s1len=) at strncpy_chk.c:26
#6 0x000000000052110a in strncpy (__len=421, __src=, __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' ..., 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' ..., 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 ) 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 a different stack trace.
Bug 1948586
A null pointer dereference can be triggered via an HTTP POST with malformed SOAP data, with an upstream patch available. We wrote a PoC cleverly named "bug_1948586.py" that triggers the issue in MediaTomb. 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.
Bug 133 (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 named "bug_133.py" that triggers the issue in MediaTomb to demonstrate the issue.
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 commit c91a8a3 and 66e43a2. We wrote a PoC cleverly named "barking_aardvark.py" that when used like so:
$ ./barking_aardvark.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:~ $