Fedora has issued an advisory on June 16: https://lists.fedoraproject.org/pipermail/package-announce/2014-June/134652.html I'm not sure exactly what the issue is, but they announced it as a security update and added a patch in this commit (which also references an upstream bug report): http://pkgs.fedoraproject.org/cgit/rb_libtorrent.git/commit/?h=f20&id=70d2aadf0aec2c26b6e79cfe881b4be14fce2231 Reproducible: Steps to Reproduce:
Whiteboard: (none) => MGA4TOO, MGA3TOO
wip
Status: NEW => ASSIGNED
Possible CVE request: http://openwall.com/lists/oss-security/2014/06/24/13 Also, Matteo fixed this in Cauldron by update to 0.16.17. Looking at the upstream discussion of this issue, it's not clear if all 0.16.x versions are affected, so you might want to test it to verify whether or not Mageia 3 and Mageia 4 are actually affected.
Version: Cauldron => 4Whiteboard: MGA4TOO, MGA3TOO => MGA3TOO
(In reply to David Walser from comment #2) > Looking at the upstream discussion of this issue, it's not clear if all > 0.16.x versions are affected, so you might want to test it to verify whether > or not Mageia 3 and Mageia 4 are actually affected. I believe all 0.16.x versions built against boost-1.5x.x are affected. F19 which uses boost-1.53.x was affected so I believe Mageia 3 will be as well.
CC: (none) => leigh123linux
libtorrent-rasterbar 0.16.17 and qttorrent have been built for mga4 and are in update testing.
CC: (none) => anaselli
We'll need an update built for Mageia 3 as well. I don't believe the qbittorrent rebuild was necessary. Looking at the package metadata, it's dynamically linked to libtorrent-rasterbar's library, and the library's major number hasn't changed. Packages built so far: libtorrent-rasterbar7-0.16.17-1.mga4 python-libtorrent-rasterbar-0.16.17-1.mga4 libtorrent-rasterbar-devel-0.16.17-1.mga4 from libtorrent-rasterbar-0.16.17-1.mga4.src.rpm
well maybe not but spec file says: BuildRequires: pkgconfig(libtorrent-rasterbar) >= 0.14.4
(In reply to Angelo Naselli from comment #6) > well maybe not but spec file says: > BuildRequires: pkgconfig(libtorrent-rasterbar) >= 0.14.4 Which by itself could mean it's statically or dynamically linked (dynamically is by far the more typical case). "urpmq --requires qbittorrent" shows the library listed, which indicates that it's dynamically linked.
on comment #7, David you are right as i wrote last night via irc i answered without thinking... sorry. Feel free to remove it from testing.
I have uploaded a patched package for Mageia 3 also. You can test it by verifying that opening upnp port 0 do not open all your ports, as described here[1]. References: [1] https://github.com/qbittorrent/qBittorrent/issues/1758
Status: ASSIGNED => NEWAssignee: matteo.pasotti => qa-bugs
Thanks Matteo! Advisory: ======================== Updated libtorrent-rasterbar packages fix security vulnerability: The libtorrent-rasterbar library was opening UPNP port 0, causing all ports to be forwarded from the router to the client machine. References: https://github.com/qbittorrent/qBittorrent/issues/1758 https://lists.fedoraproject.org/pipermail/package-announce/2014-June/134652.html ======================== Updated packages in core/updates_testing: ======================== libtorrent-rasterbar7-0.16.6-2.1.mga3 python-libtorrent-rasterbar-0.16.6-2.1.mga3 libtorrent-rasterbar-devel-0.16.6-2.1.mga3 libtorrent-rasterbar7-0.16.17-1.mga4 python-libtorrent-rasterbar-0.16.17-1.mga4 libtorrent-rasterbar-devel-0.16.17-1.mga4 from SRPMS: libtorrent-rasterbar-0.16.6-2.1.mga3.src.rpm libtorrent-rasterbar-0.16.17-1.mga4.src.rpm
CC: (none) => matteo.pasotti
Testing complete mga4 64 Started qbittorrent and checked using 'Shields Up!' at http://www.grc.com. My router doesn't log upnp port forwarding. Ran an 'All service ports' test and it showed blues for the closed ports of the computer running qbittorrent and red open ports rather than greens as it should be. Effectively putting the qbittorrent computer in DMZ. Run again with the update installed and a router reboot it then shows everything green as it should, not being forwarded.
Whiteboard: MGA3TOO => MGA3TOO has_procedure mga4-64-ok
Testing complete mga4 32 It can also be seen in the qbittorrent 'Execution Logs' from the View menu. Before ------ Shows two port 6881 but also.. 02/09/2014 16:44:36 - UPnP/NAT-PMP: Port mapping successful, message: successfully mapped port using UPnP. external port: 0 After ----- Just two... 02/09/2014 16:47:58 - UPnP/NAT-PMP: Port mapping successful, message: successfully mapped port using UPnP. external port: 6881 Confirmed at grc.com that just port 6881 was being forwarded.
Whiteboard: MGA3TOO has_procedure mga4-64-ok => MGA3TOO has_procedure mga4-32-ok mga4-64-ok
Testing complete mga3 32
Whiteboard: MGA3TOO has_procedure mga4-32-ok mga4-64-ok => MGA3TOO has_procedure mga3-32-ok mga4-32-ok mga4-64-ok
Testing complete mga3 64
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. Thanks for your input Leigh. 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 advisory has_procedure mga3-32-ok mga3-64-ok mga4-32-ok mga4-64-okCC: (none) => sysadmin-bugs
An update for this issue has been pushed to Mageia Updates repository. http://advisories.mageia.org/MGASA-2014-0364.html
Status: NEW => RESOLVEDResolution: (none) => FIXED