Re: [tor-dev] Is anyone using tor-fw-helper? (Was Re: BOINC-based Tor wrapper)

[coderman <coderman@xxxxxxxxx>]

On 7/24/15, Yawning Angel <yawning@xxxxxxxxxxxxxxx> 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
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev