summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2011-01-15Merge branch 'maint-0.2.1' into release-0.2.1tor-0.2.1.29Roger Dingledine
2011-01-150.2.1.29 changelog and blurbRoger Dingledine
2011-01-15final changelog cleanup. it'll do.Roger Dingledine
2011-01-15amend changelog for fixing --enable-openbsd-mallocRoger Dingledine
2011-01-15clean up changelog more, add blurbRoger Dingledine
2011-01-15start cleaning up 0.2.1.29 changelogRoger Dingledine
2011-01-15bump to 0.2.1.29Roger Dingledine
2011-01-15Merge branch 'maint-0.2.1' into release-0.2.1Roger Dingledine
2011-01-15Fix a couple of non-cleared key issues in hidden servicesNick Mathewson
we need to do more hunting, but this fixes the ones mentioned in 2385.
2011-01-15Zero out some more key data before freeing itNick Mathewson
Found by cypherpunks; fixes bug 2384.
2011-01-15Merge branch 'bug2352_obsize' into maint-0.2.1Nick Mathewson
2011-01-15Add missing check for hostname answer_len in dnsserv sizeNick Mathewson
This is checked elsewhere too, but let's be RFC-conformant.
2011-01-15Merge branch 'bug2332_part2' into maint-0.2.1Nick Mathewson
2011-01-15Merge branch 'bug2324_uncompress' into maint-0.2.1Nick Mathewson
2011-01-15clean up message; explain a magic number in a commentNick Mathewson
2011-01-15make the description of tolen_asserts more direNick Mathewson
We have a CVE # for this bug.
2011-01-15Fix a heap overflow found by debuger, and make it harder to make that ↵Nick Mathewson
mistake again Our public key functions assumed that they were always writing into a large enough buffer. In one case, they weren't. (Incorporates fixes from sebastian)
2011-01-15Always nul-terminate the result passed to evdns_server_add_ptr_replyNick Mathewson
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.
2011-01-15catch another overlong malloc possibility. found by cypherpunksNick Mathewson
2011-01-12Make our replacement INT32_MAX always signedNick Mathewson
The C standard says that INT32_MAX is supposed to be a signed integer. On platforms that have it, we get the correct platform-defined value. Our own replacement, however, was unsigned. That's going to cause a bug somewhere eventually.
2011-01-10Always nul-terminate the result passed to evdns_server_add_ptr_replyNick Mathewson
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.
2011-01-10Impose maximum sizes on parsed objectsNick Mathewson
An object, you'll recall, is something between -----BEGIN----- and -----END----- tags in a directory document. Some of our code, as doorss has noted in bug 2352, could assert if one of these ever overflowed SIZE_T_CEILING but not INT_MAX. As a solution, I'm setting a maximum size on a single object such that neither of these limits will ever be hit. I'm also fixing the INT_MAX checks, just to be sure.
2011-01-10Add logic in routerparse to not read overlong private keysNick Mathewson
I am not at all sure that it is possible to trigger a bug here, but better safe than sorry.
2011-01-10Update to the January 1 2011 Maxmind GeoLite Country database.Karsten Loesing
2011-01-07Remove a loud info log messageNick Mathewson
2011-01-07Correctly detect and exclude addresses outside of our virtual address rangeNick Mathewson
Found by cypherpunks; fixes more of 2328. Bug was introduced in 3623a122; first appeared in 0.2.0.5-alpha.
2011-01-06Merge branch 'bug2328_021' into maint-0.2.1Nick Mathewson
2011-01-06Notice a little faster if we're running out of virtual addressesNick Mathewson
We were not decrementing "available" every time we did ++next_virtual_addr in addressmap_get_virtual_address: we left out the --available when we skipped .00 and .255 addresses. This didn't actually cause a bug in most cases, since the failure mode was to keep looping around the virtual addresses until we found one, or until available hit zero. It could have given you an infinite loop rather than a useful message, however, if you said "VirtualAddrNetwork 127.0.0.255/32" or something broken like that. Spotted by cypherpunks
2011-01-05Handle a NULL return from addressmap_get_virtual_addressNick Mathewson
Fix for bug 2328; bugfix on 0.1.2.1-alpha; bug found by doorss.
2011-01-05Fix a double-counting bug in addrmap_get_virtual_addressNick Mathewson
We were decrementing "available" twice for each in-use address we ran across. This would make us declare that we ran out of virtual addresses when the address space was only half full.
2011-01-05Fix a SIZE_T_CEILING check in torgzip.c; noticed by cypherpunksNick Mathewson
2011-01-03Note that Tor requires Automake 1.7. Fixes bug 2305Nick Mathewson
2011-01-03Detect and disallow compression bombsNick Mathewson
2011-01-03Avoid assertion on read_file_to_str() with size==SIZE_T_CEILING-1Nick Mathewson
Spotted by doors, fixes bug 2326.
2011-01-03Check size against SIZE_T_CEILING in realloc too.Nick Mathewson
Fixes bug 2324.
2011-01-03Never include pthread.h when building for Windows.Nick Mathewson
On Windows, we never use pthreads, since it doesn't usually exist, and when it does it tends to be a little weirdly-behaved. But some mingw installations have a pthreads installed, so autoconf detects pthread.h and tells us about it. This would make us include pthread.h, which could make for trouble when the iffy pthread.h tried to include config.h. This patch changes compat.h so that we never include pthread.h on Windows. Fixes bug 2313; bugfix on 0.1.0.1-rc.
2011-01-03fix whitespace issuesNick Mathewson
2011-01-03Bump copyright statements to 2011Nick Mathewson
2010-12-21Merge remote branch 'public/bug2190_021' into maint-0.2.1Nick Mathewson
2010-12-16add blurb, change release datetor-0.2.1.28Roger Dingledine
2010-12-16Merge branch 'maint-0.2.1' into release-0.2.1Roger Dingledine
2010-12-16put 0.2.1.28 release notes in place tooRoger Dingledine
2010-12-16bump to 0.2.1.28Roger Dingledine
2010-12-16fold in changelog entryRoger Dingledine
2010-12-16Merge branch 'maint-0.2.1' into release-0.2.1Roger Dingledine
2010-12-16Merge commit 'nickm/fix_security_bug_021' into maint-0.2.1Roger Dingledine
2010-12-16merge changes filesRoger Dingledine
2010-12-16Merge branch 'maint-0.2.1' into release-0.2.1Roger Dingledine
Conflicts: src/config/geoip
2010-12-16Change gabelmoo's IP address and ports.Karsten Loesing
2010-12-15Add a changelog entryNick Mathewson
7apu2bq3rhoylwmucxizk54afw5jyda7pho4j5zdcqpwkufke7zdzwad.onion