diff options
| author | Nick Mathewson <nickm@torproject.org> | 2011-01-10 16:18:32 -0500 |
|---|---|---|
| committer | Nick Mathewson <nickm@torproject.org> | 2011-01-15 11:49:25 -0500 |
| commit | a16902b9d4b0a912eb0a252bb945cbeaaa40dacb (patch) | |
| tree | 632be0253de5e7fe3a1e2f90fe78df4140f4a04c /changes | |
| parent | 9fcc14224b689dff1be8336feeeb563199694c27 (diff) | |
| download | tor-a16902b9d4b0a912eb0a252bb945cbeaaa40dacb.tar.gz tor-a16902b9d4b0a912eb0a252bb945cbeaaa40dacb.zip | |
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.
Diffstat (limited to 'changes')
| -rw-r--r-- | changes/bug2332 | 4 |
1 files changed, 4 insertions, 0 deletions
diff --git a/changes/bug2332 b/changes/bug2332 new file mode 100644 index 0000000000..5f73ddd7af --- /dev/null +++ b/changes/bug2332 @@ -0,0 +1,4 @@ + o Minor bugfixes + - Fix a bug with handling misformed replies to reverse DNS lookup + requests in DNSPort. Bugfix on Tor 0.2.0.1-alpha. Related to a bug + reported by doorss. |