On 7/24/15, Yawning Angel yawning@schwanenlied.me wrote:
... I have less objections towards people using tor-fw-helper for bridges than for something like flashproxy or full fledged relays. ... IMO similar to relays with insufficient bandwidth, relays that can't connect to any other relay on demand as required (due to a full NAT table) do bad things to network health. This is probably an orthogonal discussion though.
loudly agree: UPnP for bridges or flashproxy, maybe - NOT relays!
UPnP exposed in a poor implementation is opening up users of a Tor instance behind it to various types of attack. it is *worse than nothing*. the Rapid7 research did not cover *all* of the *existing* severe vulnerabilities in UPnP as commonly implemented by router vendors.
command injection means even if libs are used properly, a poor implementation may call those interfaces incorrectly. i can provide horror stories, if skeptics remain.
Right. The primary concern when I started my rewrite was the libraries are really scary (since we were linking against stuff that is part of the problem on the router end, that make me nervous).
what Yawning isn't saying, is that those old libs are full of exploitable vulnerabilities.
i only hate on libpurple harder ;)
- I think the new code will work for most people for running a private bridge, or relay (though the latter with a consumer grade router may be a bad thing for network health).
agreed; don't let relays be behind UPnP!
- I think the new code is safer than the old code, because it doesn't link against 3rd party libraries with "questionable" code quality, and is in a memory safe language. YMMV there.
it is unquestionably safer.
I have reservations about deploying it as part of Tor Browser for use with flashproxy due to poor router side code. Ultimately this is the support team's call, and if they're ok with it, I will do the integration work here.
Most of the really broken (non-security) behavior only happens when the uPnP table starts to get full, which is presumably not a concern for the bridge/relay use case (Since like aliens from the planet Zeist, "There can be only one").
here's the problem: other UPnP speaking devices behind the network will stomp your mapping. it's gonna happen. so not only do you need to consider the support cost of flaky routers and poor behavior of the UPnP gateway, you also need to consider the poor behavior of other UPnP speaking software also trying to do the best thing in a world of shit that is UPee-n-Poop.
static port mappings are much better all around, for both support and reliability reasons.
- As far as support/bugfixes/maintenance from my end, there's a limit to what I can do for quirky/broken routers, and in a lot of cases this will end up as "patches accepted".
i started down a path, trying to match OUI prefix. "This router is probably broken with UPnP, are you sure?" , then checking version from login banners on webUIs, "This firmware may be out of date. You should upgrade first!" , then basically saving UPnP mapping and fuzzing behavior, "do i need to workaround behavior X? what about Y?" . . . that way is madness. just don't...
my $0.02