Always nul-terminate the result passed to evdns_server_add_ptr_reply
commita16902b9d4b0a912eb0a252bb945cbeaaa40dacb
authorNick Mathewson <nickm@torproject.org>
Mon, 10 Jan 2011 21:18:32 +0000 (10 16:18 -0500)
committerNick Mathewson <nickm@torproject.org>
Sat, 15 Jan 2011 16:49:25 +0000 (15 11:49 -0500)
tree632be0253de5e7fe3a1e2f90fe78df4140f4a04c
parent9fcc14224b689dff1be8336feeeb563199694c27
Always nul-terminate the result passed to evdns_server_add_ptr_reply

In dnsserv_resolved(), we carefully made a nul-terminated copy of the
answer in a PTR RESOLVED cell... then never used that nul-terminated
copy.  Ouch.

Surprisingly this one isn't as huge a security problem as it could be.
The only place where the input to dnsserv_resolved wasn't necessarily
nul-terminated was when it was called indirectly from relay.c with the
contents of a relay cell's payload.  If the end of the payload was
filled with junk, eventdns.c would take the strdup() of the name [This
part is bad; we might crash there if the cell is in a bad part of the
stack or the heap] and get a name of at least length
495[*]. eventdns.c then rejects any name of length over 255, so the
bogus data would be neither transmitted nor altered.

  [*] If the name was less than 495 bytes long, the client wouldn't
     actually be reading off the end of the cell.

Nonetheless this is a reasonably annoying bug.  Better fix it.

Found while looking at bug 2332, reported by doorss.  Bugfix on
0.2.0.1-alpha.
changes/bug2332 [new file with mode: 0644]
src/or/dnsserv.c