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 0x74ec9418 in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:54
#1 0x74ecb01a in __GI_abort () at abort.c:89
#2 0x74f0b72a in __libc_message (do_abort=do_abort@entry=2,
fmt=fmt@entry=0x75022c7f "*** %s ***: %s terminated\n") at
../sysdeps/posix/libc_fatal.c:175
#3 0x74fac89c in __GI___fortify_fail (msg=,
msg@entry=0x75022c10 "buffer overflow detected") at fortify_fail.c:37
#4 0x74faa8a0 in __GI___chk_fail () at chk_fail.c:28
#5 0x74fa9d49 in __strncpy_chk (s1=,
s2=, n=, s1len=) at
strncpy_chk.c:26
#6 0x0052110a 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 0x00521392 in ssdp_request_type (cmd=0x7fffd0001280
"ssdp:uuid:schemas:device:", 'a' ...,
Evt=Evt@entry=0x7fffdf7fd770) at ../upnp/src/ssdp/ssdp_server.c:634
#9 0x00524e0a in ssdp_handle_device_request
(hmsg=hmsg@entry=0x7fffd80008c0,
dest_addr=dest_addr@entry=0x7fffd8000a38) at
../upnp/src/ssdp/ssdp_device.c:157
#10 0x005209cd in ssdp_event_handler_thread
(the_data=0x7fffd80008c0) at ../upnp/src/ssdp/ssdp_server.c:797
#11 0x00523373 in WorkerThread (arg=0x798d00 )
at ../threadutil/src/ThreadPool.c:594
#12 0x770d76fa in start_thread (arg=0x7fffdf7fe700) at
pthread_create.c:333
#13 0x74f9ab5d 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 0x74ec9418 in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:54
#1 0x74ecb01a in __GI_abort () at abort.c:89
#2 0x74f0b72a in __libc_message (do_abort=do_abort@entry=2,
fmt=fmt@entry=0x75022c7f "*** %s ***: %s terminated\n") at
../sysdeps/posix/libc_fatal.c:175
#3 0x74fac89c in __GI___fortify_fail (msg=,
msg@entry=0x75022c10 "buffer overflow detected") at fortify_fail.c:37
#4 0x74faa8a0 in __GI___chk_fail () at chk_fail.c:28
#5 0x74fa9d49 in __strncpy_chk (s1=,
s2=, n=, s1len=) at
strncpy_chk.c:26
#6 0x005211a1 in strncpy (__len=404, __src=0x7fffb4001190
"uuid:", 'a' ..., __dest=0x7fffbfffe784 "") at
/usr/include/x86_64-linux-gnu/bits/string3.h:126
#7 unique_service_name (cmd=cmd@entry=0x7fffb4001190 "uuid:", 'a'
..., Evt=Evt@entry=0x7fffbfffe770) at
../upnp/src/ssdp/ssdp_server.c:544
#8 0x00521392 in ssdp_request_type (cmd=0x7fffb4001190 "uuid:",
'a' ..., Evt=Evt@entry=0x7fffbfffe770) at
../upnp/src/ssdp/ssdp_server.c:634
#9 0x00524e0a in ssdp_handle_device_request
(hmsg=hmsg@entry=0x7fffd80011a0,
dest_addr=dest_addr@entry=0x7fffd8001318) at
../upnp/src/ssdp/ssdp_device.c:157
#10 0x005209cd in ssdp_event_handler_thread
(the_data=0x7fffd80011a0) at ../upnp/src/ssdp/ssdp_server.c:797
#11 0x00523373 in WorkerThread (arg=0x798d00 )
at ../threadutil/src/ThreadPool.c:594
#12 0x770d76fa in start_thread (arg=0x7fffb700) at
pthread_create.c:
