Re: possible CVE request: rb_libtorrent opens UPNP port 0

["Vincent Danen" <vdanen () redhat com>]

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

Attachment: signature.asc
Description: OpenPGP digital signature