[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #1240 [Tor Relay]: stop calling getsockname if accept returns a bad address
#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@xxxxxxxxxxx/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@xxxxxxxxxxx/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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs