Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 24 Jun 2014 15:01:58 -0600
From: "Vincent Danen" <>
To: "OSS Security List" <>
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:

It was pointed out that according to 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.