[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #17901 [Tor]: Tor would bind ControlPort to public ip address if it has no localhost interface

#17901: Tor would bind ControlPort to public ip address if it has no localhost
interface
---------------------------------------+-----------------------------------
 Reporter:  s7r                        |          Owner:  teor
     Type:  defect                     |         Status:  needs_information
 Priority:  High                       |      Milestone:  Tor:
Component:  Tor                        |  0.2.8.x-final
 Severity:  Major                      |        Version:  Tor: 0.2.6.10
 Keywords:  027-backport 026-backport  |     Resolution:
Parent ID:                             |  Actual Points:
  Sponsor:                             |         Points:
---------------------------------------+-----------------------------------

Comment (by teor):

 Replying to [comment:21 teor]:
 > Looking at the code in parse_port_config, tor converts the default
 address string "127.0.0.1" using tor_addr_parse, so there's no possibility
 tor will bind to any other address but 127.0.0.1. (Even if /etc/hosts maps
 127.0.0.1 to some other address.)
 >
 > If this is an issue, I need to know how tor's explicit request to bind
 to 127.0.0.1 ends up binding to another address, and how tor can detect
 that. It would also help to have `ifconfig` output from one of these
 hosts.

 I've looked up some of the reference documentation for FreeBSD and OpenVZ:
 * FreeBSD: "Inside a jail, access to the loopback address 127.0.0.1 is
 redirected to the first IP address assigned to the jail."
   * https://www.freebsd.org/doc/handbook/jails-ezjail.html
   * we can probably detect this using getsockname after binding the
 listener(!) like the UDP socket hack does. It would be safer to run the
 UDP socket hack on 127.0.0.1 and see what result we get.
   * I suspect that "the first IP address assigned to the jail" will be on
 an interface without the loopback flag. That's another way of detecting
 this scenario.

 * OpenVZ configs often assign 127.0.0.1/32 to venet0. Some have a loopback
 interface with 127.0.0.0/8, others don't.
   * http://itknowledgeexchange.techtarget.com/security-admin/openvz-and-
 ubuntu-no-loopback-adapter/
   * http://forum.openvz.org/index.php?t=msg&goto=26825
   * venet0 doesn't have the loopback flag. We could detect these sorts of
 configs this way.
     * http://shorewall.net/OpenVZ.html#idp8779049328
   * venet0 is the default route, even when it's only configured with
 127.0.0.1, which I believe is the root cause of this security issue
     * https://forum.openvz.org/index.php?t=msg&goto=47137

 And if 127.0.0.1 is missing entirely, with no redirect in place, we'll
 handle it in #17991. (It's not a security issue, tor will simply fail to
 bind the listener to 127.0.0.1.)

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/17901#comment:22>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs