[tor-bugs] #1240 [Tor Relay]: stop calling getsockname if accept returns a bad address

[Tor Bug Tracker & Wiki]

#1240: stop calling getsockname if accept returns a bad address
-----------------------+----------------------------------------------------
 Reporter:  Sebastian  |           Type:  defect   
   Status:  closed     |       Priority:  minor    
Milestone:             |      Component:  Tor Relay
  Version:  0.2.1.22   |     Resolution:  Not a bug
 Keywords:             |         Parent:           
   Points:             |   Actualpoints:           
-----------------------+----------------------------------------------------

Old description:

> r1eo| can anyone explain: 1) why connection_handle_listener_read() goes
> far
>          if getsockname() failed and do not return after such. 2) why
>          getsockname() called at all, what purpose for retrieve local
> addr and
>          put it as remote? at least fail of check_sockaddr() can be
> triggered
>          remotely in theory.
> r1eo| http://archives.seul.org/or/cvs/Apr-2005/msg00100.html it's
>          introduced getsockname(). but I have the same questions still.
> And one:
>          if accept() failed to return correct peer-address, then
> getpeername()
>          failing too?
> http://archives.neohapsis.com/archives/bind/2001/0025.html
>          http://www.mail-archive.com/freebsd-
> net at freebsd.org/msg00901.html
>          funny, but such accepted conn with zero addr is broken anyway.
> so if tor
>          filled it with self addr bug him. wonder if it exploitable for
> spoofing log
>          at least.
> r1eo| someone nmap'ed moria in 2005.
> r1eo| just for clear: nothing stops sending created cell and other for
> today even
>          if addr faked.
> r1eo| http://archives.seul.org/or/cvs/Apr-2005/msg00100.html "This just
>          happened on moria2"
> r1eo| http://paste.debian.net/58458/plain/58458 prevent fooling themself.
>          socket returned by accept() with zero addr, as result of scan
> and timing
>          issues in some kernels. such conn is broken.
>
> [Automatically added by flyspray2trac: Operating System: All]

New description:

 r1eo| can anyone explain: 1) why connection_handle_listener_read() goes
 far
          if getsockname() failed and do not return after such. 2) why
          getsockname() called at all, what purpose for retrieve local addr
 and
          put it as remote? at least fail of check_sockaddr() can be
 triggered
          remotely in theory.
 r1eo| http://archives.seul.org/or/cvs/Apr-2005/msg00100.html it's
          introduced getsockname(). but I have the same questions still.
 And one:
          if accept() failed to return correct peer-address, then
 getpeername()
          failing too?
 http://archives.neohapsis.com/archives/bind/2001/0025.html
          http://www.mail-archive.com/freebsd-net@freebsd.org/msg00901.html
          funny, but such accepted conn with zero addr is broken anyway. so
 if tor
          filled it with self addr bug him. wonder if it exploitable for
 spoofing log
          at least.
 r1eo| someone nmap'ed moria in 2005.
 r1eo| just for clear: nothing stops sending created cell and other for
 today even
          if addr faked.
 r1eo| http://archives.seul.org/or/cvs/Apr-2005/msg00100.html "This just
          happened on moria2"
 r1eo| http://paste.debian.net/58458/plain/58458 prevent fooling themself.
          socket returned by accept() with zero addr, as result of scan and
 timing
          issues in some kernels. such conn is broken.

 [Automatically added by flyspray2trac: Operating System: All]

--

Comment(by nickm):

 Note for the future: let's not close bugs just because the bug reporter
 asks for it, without confirming that their initial report is indeed wrong.
 Apparently this is real, and is #4747

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/1240#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online