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
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.
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 ([email protected]=6) at ../sysdeps/unix/sysv/linux/raise.c:54 #1 0x00007ffff4ecb01a in __GI_abort () at abort.c:89 #2 0x00007ffff4f0b72a in __libc_message ([email protected]=2, [email protected]=0x7ffff5022c7f "*** %s ***: %s terminated\n") at ../sysdeps/posix/libc_fatal.c:175 #3 0x00007ffff4fac89c in __GI___fortify_fail (msg=
, [email protected]=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 ([email protected]=0x7fffd0001280 "ssdp:uuid:schemas:device:", 'a' ..., [email protected]=0x7fffdf7fd770) at ../upnp/src/ssdp/ssdp_server.c:532 #8 0x0000000000521392 in ssdp_request_type (cmd=0x7fffd0001280 "ssdp:uuid:schemas:device:", 'a' ..., [email protected]=0x7fffdf7fd770) at ../upnp/src/ssdp/ssdp_server.c:634 #9 0x0000000000524e0a in ssdp_handle_device_request ([email protected]=0x7fffd80008c0, [email protected]=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.
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 (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 named "
bug_133.py" that triggers the issue in MediaTomb to demonstrate the issue.
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:
[email protected]:~ $ cat /usr/share/mediatomb/web/danger_zone Better call Kenny Loggins [email protected]:~ $
See the details above which link to fixing commits where applicable. Since this is a third-party library used within a fork of mediatomb and impacts multiple Linux distributions, it is up to each one to resolve the issues in their installation. In the meantime, restrict access to the mediatomb server.
Proof of Concept
All information within TRA advisories is provided “as is”, without warranty of any kind, including the implied warranties of merchantability and fitness for a particular purpose, and with no guarantee of completeness, accuracy, or timeliness. Individuals and organizations are responsible for assessing the impact of any actual or potential security vulnerability.
Tenable takes product security very seriously. If you believe you have found a vulnerability in one of our products, we ask that you please work with us to quickly resolve it in order to protect customers. Tenable believes in responding quickly to such reports, maintaining communication with researchers, and providing a solution in short order.
For more details on submitting vulnerability information, please see our Vulnerability Reporting Guidelines page.
If you have questions or corrections about this advisory, please email [email protected]