Nick Mathewson [Mon, 24 Jan 2011 21:03:14 +0000 (16:03 -0500)]
Make the DH parameter we use for TLS match the one from Apache's mod_ssl
Our regular DH parameters that we use for circuit and rendezvous
crypto are unchanged. This is yet another small step on the path of
protocol fingerprinting resistance.
Sebastian Hahn [Mon, 7 Feb 2011 14:40:14 +0000 (15:40 +0100)]
Locking failures on windows are indicated by EACCES
Patch our implementation of tor_lockfile_lock() to handle this case
correctly. Also add a note that blocking behaviour differs from windows
to *nix. Fixes bug 2504, issue pointed out by mobmix.
Nick Mathewson [Tue, 25 Jan 2011 22:27:25 +0000 (17:27 -0500)]
Avoid sketchy integer cast in cbt code
When calling circuit_build_times_shuffle_and_store_array, we were
passing a uint32_t as an int. arma is pretty sure that this can't
actually cause a bug, because of checks elsewhere in the code, but
it's best not to pass a uint32_t as an int anyway.
Nick Mathewson [Wed, 26 Jan 2011 01:39:44 +0000 (20:39 -0500)]
Add client code to detect attempts to connect to 127.0.0.1 etc
We detect and reject said attempts if there is no chosen exit node or
circuit: connecting to a private addr via a randomly chosen exit node
will usually fail (if all exits reject private addresses), is always
ill-defined (you're not asking for any particular host or service),
and usually an error (you've configured all requests to go over Tor
when you really wanted to configure all _remote_ requests to go over
Tor).
This can also help detect forwarding loop requests.
Mike Perry [Mon, 17 Jan 2011 06:07:31 +0000 (06:07 +0000)]
Comment remaining CBT functions.
Left circuit_build_times_get_bw_scale() uncommented because it is in the wrong
place due to an improper bug2317 fix. It needs to be moved and renamed, as it
is not a cbt parameter.
Mike Perry [Sun, 16 Jan 2011 02:14:15 +0000 (02:14 +0000)]
Fix bug #2004 by demoting a log message.
To quote arma: "So instead of stopping your CBT from screaming, you're just
going to throw it in the closet and hope you can't hear it?"
Yep. The log message can happen because at 95% point on the curve, we can be
way beyond the max timeout we've seen, if the curve has few points and is
shallow.
Also applied Nick's rule of thumb for rewriting some other notice log messages
to read like how you would explain them to a raving lunatic on #tor who was
shouting at you demanding what they meant. Hopefully the changes live up to
that standard.
Nick Mathewson [Tue, 25 Jan 2011 22:15:22 +0000 (17:15 -0500)]
Fix bug in verifying directory signatures with short digests
If we got a signed digest that was shorter than the required digest
length, but longer than 20 bytes, we would accept it as long
enough.... and then immediately fail when we want to check it.
Fixes bug 2409; bug in 0.2.2.20-alpha; found by piebeer.
Sebastian Hahn [Tue, 25 Jan 2011 14:28:58 +0000 (15:28 +0100)]
Fix assert for relay/bridge state change
When we added support for separate client tls certs on bridges in a2bb0bfdd5 we forgot to correctly initialize this when changing
from relay to bridge or vice versa while Tor is running. Fix that
by always initializing keys when the state changes.
Nick Mathewson [Mon, 24 Jan 2011 21:03:14 +0000 (16:03 -0500)]
Make the DH parameter we use for TLS match the one from Apache's mod_ssl
Our regular DH parameters that we use for circuit and rendezvous
crypto are unchanged. This is yet another small step on the path of
protocol fingerprinting resistance.
Nick Mathewson [Wed, 19 Jan 2011 18:22:50 +0000 (13:22 -0500)]
Fix two more SIZE_T_CEILING issues
This patch imposes (very long) limits on the length of a line in a
directory document, and on the length of a certificate. I don't
think it should actually be possible to overrun these remotely,
since we already impose a maximum size on any directory object we're
downloading, but a little defensive programming never hurt anybody.
Roger emailed me that doorss reported these on IRC, but nobody seems
to have put them on the bugtracker.
Sebastian Hahn [Thu, 30 Dec 2010 18:54:13 +0000 (19:54 +0100)]
Sanity-check consensus param values
We need to make sure that the worst thing that a weird consensus param
can do to us is to break our Tor (and only if the other Tors are
reliably broken in the same way) so that the majority of directory
authorities can't pull any attacks that are worse than the DoS that
they can trigger by simply shutting down.
One of these worse things was the cbtnummodes parameter, which could
lead to heap corruption on some systems if the value was sufficiently
large.
This commit fixes this particular issue and also introduces sanity
checking for all consensus parameters.
Nick Mathewson [Mon, 10 Jan 2011 21:18:32 +0000 (16:18 -0500)]
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.
Nick Mathewson [Wed, 12 Jan 2011 19:29:38 +0000 (14:29 -0500)]
Make our replacement INT32_MAX always signed
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.
Nick Mathewson [Mon, 10 Jan 2011 22:24:16 +0000 (17:24 -0500)]
Pull up more data when parsing socks messages
Previously, we only looked at up to 128 bytes. This is a bad idea
since socks messages can be at least 256+x bytes long. Now we look at
up to 512 bytes; this should be enough for 0.2.2.x to handle all valid
SOCKS messages. For 0.2.3.x, we can think about handling trickier
cases.