Fedora has issued an advisory on May 1: https://lists.fedoraproject.org/pipermail/package-announce/2014-May/133219.html The issue is fixed upstream in 1.9, and with this commit: https://github.com/miniupnp/miniupnp/commit/3a87aa2f10bd7f1408e1849bdb59c41dd63a9fe9 The 0ad and megaglest packages were also rebuilt for Fedora's update to 1.9 (probably a libmajor change). Mageia 3 and Mageia 4 are also affected. A CVE was requested on April 30 but there has been no reply: http://www.openwall.com/lists/oss-security/2014/04/30/3 Reproducible: Steps to Reproduce:
Whiteboard: (none) => MGA4TOO, MGA3TOO
Updated package uploaded for Cauldron, dependent packages rebuilt. Note that the 0ad and dolphin-emu rebuilds failed: http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20140514190004.luigiwalser.valstar.19818/log/0ad-0.0.15-0.alpha.4.mga5/build.0.20140514190315.log http://pkgsubmit.mageia.org/uploads/failure/cauldron/tainted/release/20140514190458.luigiwalser.valstar.2378/log/dolphin-emu-4.0.2-2.mga5.tainted/build.0.20140514190503.log Patched packages uploaded for Mageia 3 and Mageia 4. Advisory: ======================== Updated miniupnpc packages fix security vulnerability: The miniupnpc library before 1.9 may be vulnerable to a denial of service due to a buffer overrun that can be triggered by something on the network. References: https://lists.fedoraproject.org/pipermail/package-announce/2014-May/133219.html ======================== Updated packages in core/updates_testing: ======================== libminiupnpc8-1.6-3.1.mga3 libminiupnpc-devel-1.6-3.1.mga3 libminiupnpc9-1.8-2.1.mga4 libminiupnpc-devel-1.8-2.1.mga4 from SRPMS: miniupnpc-1.6-3.1.mga3.src.rpm miniupnpc-1.8-2.1.mga4.src.rpm
CC: (none) => fundawang, juan.baptiste, mageia, remiVersion: Cauldron => 4Assignee: fundawang => qa-bugsWhiteboard: MGA4TOO, MGA3TOO => MGA3TOO
For testing purposes, megaglest is the primary user of this library.
(In reply to David Walser from comment #2) > For testing purposes, megaglest is the primary user of this library. That's a nice test program :-D
First test case post so correct me if I am wrong. I will also be trying this later tonight to confirm. Possible test case: Download latest miniupnpc from http://miniupnp.tuxfamily.org/files/ Extract # make install $ /usr/bin/upnpc -a Expected "List of UPNP devices found on the network :" Upgrade libminiupnpc Retest for same device list.
CC: (none) => dpremy
miniupnpc is the package that's being updated here, so you wouldn't want to build that yourself. I'm not sure where you're getting that upnpc binary from. If it links against the system miniupnpc library, I guess it could be used for a test.
In my test the system library was used and upnpc wouldn't run without the system library being installed. I did check for that just to be safe. It doesn't seem that upnpc is included in this patch, or the system, so I believe this should be a valid test. Please correct me if I am wrong, I will retest on hardware now to verify that the system library is used and upnpc fails when the library is removed. I am curious as to why upnpc is not included in the package and only the library is.
As long as it's using the system library, that's fine. So upnpc comes from the same tarball, eh? Interesting. It's not apparent why it's not built in the SPEC, as it certainly isn't deleted in %install, but maybe one of the cmake arguments used disables building it.
In that case, if it is the miniupnpc tarball itself that you're building, you probably should *not* run "make install" as that should replace the system library with the one you just built. After the build finishes (which you don't need to be root to do), you should be able to execute the upnpc executable in the build directory.
Disreguard my test, you are correct, the makefile showed the library was copied over and used. It looks like I'll be installing megaglest, shucks. :)
I would test this against M4. So if I understand it right if both packages are installed and running this update is validated ??? Roelof
CC: (none) => r.wobben
Testing complete mga4 64 Tested as far as possible with megaglest (it's a game) using the online game but megaglest currently shows a message that it's an outdated version and so cannot connect to other games. Tried to host a game but nobody connected to it. No errors/crashes though so I think that's as tested as we can do.
Whiteboard: MGA3TOO => MGA3TOO has_procedure mga4-64-ok
Testing complete mga3 32 Unable to run megaglest in VBox so tried on my old intel laptop. Similar issues with megaglest version plus when trying to actually play a game megaglest segfaulted (unrelated) and left my laptop in 800x600. Tested as well as I'm able.
Whiteboard: MGA3TOO has_procedure mga4-64-ok => MGA3TOO has_procedure mga3-32-ok mga4-64-ok
Please read the validation process again Roelof, which explains this. When it is tested on all arch's then it can be validated.
In VirtualBox, M3, KDE, 64-bit Package(s) under test: lib64miniupnpc8 megaglest default install of lib64miniupnpc8 and megaglest [root@localhost wilcal]# urpmi lib64miniupnpc8 Package lib64miniupnpc8-1.6-3.mga3.x86_64 is already installed [root@localhost wilcal]# urpmi megaglest Package megaglest-3.7.1-3.mga3.x86_64 is already installed megaglest crashes on launch. Test platform: Intel Core i7-2600K Sandy Bridge 3.4GHz GIGABYTE GA-Z68X-UD3-B3 LGA 1155 MoBo GIGABYTE GV-N440D3-1GI Nvidia GeForce GT 440 (Fermi) 1GB RTL8111/8168B PCI Express 1Gbit Ethernet DRAM 16GB (4 x 4GB) Mageia 4 64-bit, Nvidia driver virtualbox-4.3.10-1.1.mga4.x86_64 virtualbox-guest-additions-4.3.10-1.1.mga4.x86_64
CC: (none) => wilcal.int
Created attachment 5162 [details] megaglest crash in terminal
Testing complete mga4 32
Whiteboard: MGA3TOO has_procedure mga3-32-ok mga4-64-ok => MGA3TOO has_procedure mga3-32-ok mga4-32-ok mga4-64-ok
Testing complete mga3 64 Just ensured it updated cleanly, as megaglest won't run in vbox.
Whiteboard: MGA3TOO has_procedure mga3-32-ok mga4-32-ok mga4-64-ok => MGA3TOO has_procedure mga3-32-ok mga3-64-ok mga4-32-ok mga4-64-ok
Validating. Advisory uploaded. Could sysadmin please push to 3 & 4 updates Thanks
Keywords: (none) => validated_updateWhiteboard: MGA3TOO has_procedure mga3-32-ok mga3-64-ok mga4-32-ok mga4-64-ok => MGA3TOO has_procedure advisory mga3-32-ok mga3-64-ok mga4-32-ok mga4-64-okCC: (none) => sysadmin-bugs
Update pushed: http://advisories.mageia.org/MGASA-2014-0224.html
Status: NEW => RESOLVEDCC: (none) => tmbResolution: (none) => FIXED
CVE-2014-3985 has been allocated for this: http://openwall.com/lists/oss-security/2014/06/07/2
Summary: miniupnpc new DoS security issue => miniupnpc new DoS security issue (CVE-2014-3985)