Bug 906044 - CVE-2012-5958 CVE-2012-5959 CVE-2012-5960 CVE-2012-5961 CVE-2012-5962 CVE-2012-5963 CVE-2012-5964 CVE-2012-5965 libupnp: Multiple stack-based buffer overflows in unique_service_name() by processing specially-crafted SSDP request (VU#922681) [fedora-all]
CVE-2012-5958 CVE-2012-5959 CVE-2012-5960 CVE-2012-5961 CVE-2012-5962 CVE-201...
Product: Fedora
Classification: Fedora
Component: mediatomb (Show other bugs)
All Linux
high Severity high
: ---
: ---
Assigned To: Gwyn Ciesla
Fedora Extras Quality Assurance
: Security, SecurityTracking
Depends On:
Blocks: CVE-2012-5958/CVE-2012-5959/CVE-2012-5960/CVE-2012-5961/CVE-2012-5962/CVE-2012-5963/CVE-2012-5964/CVE-2012-5965
  Show dependency treegraph
Reported: 2013-01-30 12:16 EST by Vincent Danen
Modified: 2013-03-28 16:27 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Release Note
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-02-21 00:31:38 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Vincent Danen 2013-01-30 12:16:47 EST
This is an automatically created tracking bug!  It was created to ensure
that one or more security vulnerabilities are fixed in affected versions
of Fedora.

For comments that are specific to the vulnerability please use bugs filed
against the "Security Response" product referenced in the "Blocks" field.

For more information see:

When creating a Bodhi update request, please use the bodhi submission link
noted in the next comment(s).  This will include the bug IDs of this
tracking bug as well as the relevant top-level CVE bugs.

Please also mention the CVE IDs being fixed in the RPM changelog and the
Bodhi notes field when available.

Please note: this issue affects multiple supported versions of Fedora.
Only one tracking bug has been filed; please ensure that it is only closed
when all affected versions are fixed.

[bug automatically created by: add-tracking-bugs]
Comment 1 Vincent Danen 2013-01-30 12:16:54 EST
Please use the following update submission link to create the Bodhi
request for this issue as it contains the top-level parent bug(s) as well
as this tracking bug.  This will ensure that all associated bugs get
updated when new packages are pushed to stable.

Please also ensure that the "Close bugs when update is stable" option
remains checked.

Bodhi update submission link:
Comment 2 Vincent Danen 2013-01-30 12:18:08 EST
If at all possible, this should be made to use the system libupnp library so that future vulnerabilities in libupnp do not require a rebuild of this package.
Comment 3 Fedora Update System 2013-02-12 14:23:30 EST
mediatomb-0.12.1-23.fc17 has been submitted as an update for Fedora 17.
Comment 4 Fedora Update System 2013-02-12 14:23:47 EST
mediatomb-0.12.1-16.fc16 has been submitted as an update for Fedora 16.
Comment 5 Fedora Update System 2013-02-12 14:24:03 EST
mediatomb-0.12.1-23.fc18 has been submitted as an update for Fedora 18.
Comment 6 Fedora Update System 2013-02-12 23:26:27 EST
Package mediatomb-0.12.1-23.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing mediatomb-0.12.1-23.fc17'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
Comment 7 Fedora Update System 2013-02-21 00:31:44 EST
mediatomb-0.12.1-23.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 8 Fedora Update System 2013-02-21 00:48:01 EST
mediatomb-0.12.1-23.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 9 Travis Suel 2013-02-21 23:25:12 EST
This update appears to have introduced two bugs, both related to the unbundling of mediatomb's UPnP library.

The first is that mediatomb no longer respects the port setting in its config file and appears to be caused by this part of the unbundle patch:

diff -r -U3 mediatomb-0.12.1.orig/src/server.cc mediatomb-0.12.1/src/server.cc
--- mediatomb-0.12.1.orig/src/server.cc 2010-03-25 09:58:11.000000000 -0500
+++ mediatomb-0.12.1/src/server.cc  2013-02-12 12:01:08.955475877 -0600
@@ -166,7 +166,7 @@
     if (storage->threadCleanupRequired())
         cb = (void *)static_cleanup_callback;

-    ret = UpnpInit(ip.c_str(), port, 0, cb);
+    ret = UpnpInit(ip.c_str(), 0);

     if (ret != UPNP_E_SUCCESS)

I believe the replaced line should be:

+    ret = UpnpInit(ip.c_str(), (unsigned short) port);

The second bug is that streaming to the PlayStation 3 is now broken.  It is possible to browse the file hierarchy, but when trying to play of file, the PS3 fails to play the file with the following error message:

"Media Server Error: A network error has occurred. (00000193)"
Comment 10 Gwyn Ciesla 2013-02-22 10:47:24 EST
Try the build that just finished in rawhide from koji, it incorporates your patch change.  Do you get any log or console errors when you attempt PS3 streaming?

Comment 11 Travis Suel 2013-02-22 23:57:52 EST
That build does fix the port problem.

As for the PlayStation 3 problem, there appears to be no output indicating an error state.  The mediatomb log contains nothing but the startup messages about binding to an IP address and port.

However, I have found that when I try to visit the web interface in a web browser, I am prompted for a username and password despite not having configured mediatomb to perform authentication.  Even when trying the username and password in the config file (/etc/mediatomb/config.xml), I cannot get past the username and password page.

Looking through MediaTomb's UPnP fork...I guess it's a fork of libupnp, it appears they added some sort of basic HTTP server which I'm guessing is required for PS3 support.  So removing the bundled UPnP library may have to be done upstream.

For now, I'm working around the issue by rebuilding the RPM myself without the unbundling patch.
Comment 12 Gwyn Ciesla 2013-03-19 09:14:46 EDT
Turns out that the version mediatomb bundles isn't affected, requested update from upstream and bundling exception from FPC.
Comment 13 Vincent Danen 2013-03-19 12:44:37 EDT
(In reply to comment #12)
> Turns out that the version mediatomb bundles isn't affected, requested
> update from upstream and bundling exception from FPC.

What does this mean?  That you want to continue using the embedded libupnp rather than the system one?  It might not be vulnerable to this flaw, but can you make the same guarantee about future flaws?

I think using the system libupnp is the right thing to do.
Comment 14 Gwyn Ciesla 2013-03-19 12:48:39 EDT
I agree, but upstream has rejected my request to use modern libupnp.  They've also been patching their own version in their git repo for security fixed.

Comment 15 Vincent Danen 2013-03-19 12:54:50 EDT
Oh.  So they'v essentially forked it for their own exclusive use.  Ok, the exception request makes more sense now (it's a nuisance, but if they've been patching it for themselves and it's no longer a reflection of upstream libupnp, then I suppose there's not too much we can do if they're not interested in using a newer/upstream version).

Thanks for checking, Jon.  This is unfortunate, but it makes sense.
Comment 16 Gwyn Ciesla 2013-03-19 12:59:28 EDT
I agree with A.  I think B. is generous. :) But it is what it is.
Comment 17 Vincent Danen 2013-03-19 13:04:23 EDT
Indeed.  =)  Thanks again.

Note You need to log in before you can comment on or make changes to this bug.