[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <6CD0E58F-3A90-47CA-9EDF-D8B745B587C4@redhat.com>
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.
