From http://archives.seul.org/tor/relays/Mar-2010/msg00006.html :
As I understand it, the bug should show up on relays that don't set
Address to an IP address (so they need to resolve their Address
line or their hostname to guess their IP address), and their
hostname or Address line fails to resolve -- at that point they'll
pick a random 4 bytes out of memory and call that their address. At
the same time, relays that *do* successfully resolve their address
will ignore the result, and only come up with a useful address if
their interface address happens to be a public IP address.
Treat strings returned from signed_descriptor_get_body_impl() as not
NUL-terminated. Since the length of the strings is available, this is
not a big problem.
Discovered by rieo.
Another dereference-then-NULL-check sequence. No reports of this bug
triggered in the wild. Fixes bugreport 1256.
Thanks to ekir for discovering and reporting this bug.
Fix a dereference-then-NULL-check sequence. This bug wasn't triggered
in the wild, but we should fix it anyways in case it ever happens.
Also make sure users get a note about this being a bug when they
see it in their log.
Thanks to ekir for discovering and reporting this bug.
We used to only zero the first ptrsize bytes of the cipher. Since
cipher is large enough, we didn't zero too many bytes. Discovered
and fixed by ekir. Fixes bug 1254.
This time, set the SSL3_FLAGS_ALLOW_UNSAFE_RENEGOTIATION flag on every
version before OpenSSL 0.9.8l. I can confirm that the option value (0x0010)
wasn't reused until OpenSSL 1.0.0beta3.
Tor has tor_lookup_hostname(), which prefers ipv4 addresses automatically.
Bug 1244 occured because gethostbyname() returned an ipv6 address, which
Tor cannot handle currently. Fixes bug 1244; bugfix on 0.0.2pre25.
Reported by Mike Mestnik.
The problem was that we didn't allocate enough memory on 32-bit
platforms with 64-bit time_t. The memory leak occured every time
we fetched a hidden service descriptor we've fetched before.
For most linking setups, this doesn't matter. But for some setups, when
statically linking openssl, it does matter, since you need to link things
with dependencies before you link things they depend on.
Fix for bug 1237.
In brief: you mustn't use the SSL3_FLAG solution with anything but 0.9.8l,
and you mustn't use the SSL_OP solution with anything before 0.9.8m, and
you get in _real_ trouble if you try to set the flag in 1.0.0beta, since
they use it for something different.
For the ugly version, see my long comment in tortls.c
We need to do this because Apple doesn't update its dev-tools headers
when it updates its libraries in a security patch. On the bright
side, this might get us out of shipping a statically linked OpenSSL on
OSX.
May fix bug 1225.
[backported]
We were checking for msg==NULL, but not lib or proc. This case can
only occur if we have an error whose string we somehow haven't loaded,
but it's worth coding defensively here.
Spotted by rieo on IRC.
this case can now legitimately happen, if you have a cached v2 status
from moria1, and you run with the new list of dirservers that's missing
the old moria1. it's nothing to worry about; the file will die off in
a month or two.
It turns out that OpenSSL 0.9.8m is likely to take a completely
different approach for reenabling renegotiation than OpenSSL 0.9.8l
did, so we need to work with both. :p Fixes bug 1158.
(patch by coderman; commit message by nickm)
Avoid crashing if the client is trying to upload many bytes and the
circuit gets torn down at the same time, or if the flip side
happens on the exit relay. Bugfix on 0.2.0.1-alpha; fixes bug 1150.
* debian-merge: (37 commits)
New upstream version
bump to 0.2.1.20
Move moria1 and Tonga to alternate IP addresses.
read the "circwindow" parameter from the consensus
Code to parse and access network parameters.
Revert "Teach connection_ap_can_use_exit about Exclude*Nodes"
Work around a memory leak in openssl 0.9.8g (and maybe others)
Teach connection_ap_can_use_exit about Exclude*Nodes
make some bug 1090 warnings go away
Fix a memory leak when parsing a ns
Fix obscure 64-bit big-endian hidserv bug
turns out the packaging changes aren't in 0.2.1.20
update changelog with bundle details
Use an _actual_ fix for the byte-reverse warning.
Use a simpler fix for the byte-reversing warning
Fix compile warnings on Snow Leopard
Add getinfo accepted-server-descriptor. Clean spec.
Reduce log level for bug case that we now know really exists.
Only send reachability status events on overall success/failure
update the README instructions and OS X makefiles
...
* commit 'tor-0.2.1.20': (36 commits)
bump to 0.2.1.20
Move moria1 and Tonga to alternate IP addresses.
read the "circwindow" parameter from the consensus
Code to parse and access network parameters.
Revert "Teach connection_ap_can_use_exit about Exclude*Nodes"
Work around a memory leak in openssl 0.9.8g (and maybe others)
Teach connection_ap_can_use_exit about Exclude*Nodes
make some bug 1090 warnings go away
Fix a memory leak when parsing a ns
Fix obscure 64-bit big-endian hidserv bug
turns out the packaging changes aren't in 0.2.1.20
update changelog with bundle details
Use an _actual_ fix for the byte-reverse warning.
Use a simpler fix for the byte-reversing warning
Fix compile warnings on Snow Leopard
Add getinfo accepted-server-descriptor. Clean spec.
Reduce log level for bug case that we now know really exists.
Only send reachability status events on overall success/failure
update the README instructions and OS X makefiles
Avoid segfault when accessing hidden service.
...
To fix a major security problem related to incorrect use of
SSL/TLS renegotiation, OpenSSL has turned off renegotiation by
default. We are not affected by this security problem, however,
since we do renegotiation right. (Specifically, we never treat a
renegotiated credential as authenticating previous communication.)
Nevertheless, OpenSSL's new behavior requires us to explicitly
turn renegotiation back on in order to get our protocol working
again.
Amusingly, this is not so simple as "set the flag when you create
the SSL object" , since calling connect or accept seems to clear
the flags.
For belt-and-suspenders purposes, we clear the flag once the Tor
handshake is done. There's no way to exploit a second handshake
either, but we might as well not allow it.
The first happens on an error case when a controller wants an
impossible directory object. The second happens when we can't write
our fingerprint file.
