Date: Tue, 24 Jun 2014 15:01:58 -0600 From: "Vincent Danen" <vdanen@...hat.com> To: "OSS Security List" <oss-security@...ts.openwall.com> Subject: Re: possible CVE request: rb_libtorrent opens UPNP port 0 On 06/24/2014, at 8:18 AM, Vincent Danen wrote: > It was brought to my attention today that a potential flaw in rb_libtorrent exists where it will open UPNP port 0, which (by the description of the issue) opens all ports to the system running rb_libtorrent via the given firewall (so even if you had, say, only port 22 open to the machine to start, fire up an application using rb_libtorrent such as qbittorrent, and all ports are forwarding to that machine). > > I can't find any references on whether or not this is part of the UPNP spec or known behaviour, however. Either way, I suppose that anyone running such a bittorrent client isn't expecting that all ports start forwarding (but, as a result, I'm not sure if this is malfunctioning firewall which is where knowing whether or not this is according to spec would be good). > > So I'm not just asking for a CVE, but whether or not it's a flaw (I don't know enough about UPNP to hazard a guess). > > Here's some references: > > https://github.com/qbittorrent/qBittorrent/issues/1758 > https://lists.fedoraproject.org/pipermail/package-announce/2014-June/134652.html > https://bugs.mageia.org/show_bug.cgi?id=13582 It was pointed out that according to http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf UDP port 0 is meant to do this: " 2.2.16. ExternalPort This variable represents the external port that the NAT gateway would “listen” on for connection requests to a corresponding InternalPort on an InternalClient.. Inbound packets to this external port on the WAN interface of the gateway should be forwarded to InternalClient on the InternalPort on which the message was received. If this value is specified as a wildcard (i.e. 0), connection request on all external ports (that are not otherwise mapped) will be forwarded to InternalClient. In the wildcard case, the value(s) of InternalPort on InternalClient are ignored by the IGD for those connections that are forwarded to InternalClient. Obviously only one such entry can exist in the NAT at any time and conflicts are handled with a “first write wins” behavior " Seems to be a newer addition to the spec though, as it also indicates that not all NAT implementations will support it. In light of this, I suspect a CVE is warranted here. -- Vincent Danen / Red Hat Product Security Download attachment "signature.asc" of type "application/pgp-signature" (711 bytes)
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.