Age | Commit message (Collapse) | Author |
|
|
|
Issues noted by cypherpunks on #18162
|
|
This closes bug 18162; bugfix on a45b1315909c9, which fixed a related
issue long ago.
In addition to the #18162 issues, this fixes a signed integer overflow
in smarltist_add_all(), which is probably not so great either.
|
|
|
|
There is a bug in the overlap-checking in strlcat that can crash Tor
servers. Fixes bug 15205; this is an OSX bug, not a Tor bug.
|
|
fixes bug 15088. patch from sanic.
|
|
Backports some commits from tor master.
|
|
|
|
This is a good idea in case the caller stupidly doesn't check the
return value from baseX_decode(), and as a workaround for the
current inconsistent API of base16_decode.
Prevents any fallout from bug 14013.
|
|
|
|
|
|
The POODLE attack doesn't affect Tor, but there's no reason to tempt
fate: SSLv3 isn't going to get any better.
|
|
|
|
Also, make sure we will compile correctly on systems where they
finally rip it out.
Fixes issue #13325. Caused by this openbsd commit:
​http://marc.info/?l=openbsd-cvs&m=140768179627976&w=2
Reported by Fredzupy.
|
|
Fixes bug 13295; bugfix on 0.2.5.3-alpha.
The alternative here is to call crypto_global_init() from tor-resolve,
but let's avoid linking openssl into tor-resolve for as long as we
can.
|
|
Fixes bug 13081; bugfix on 0.2.5.1-alpha. Patch from "NewEraCracker."
|
|
Most of these are in somewhat non-obvious code where it is probably
a good idea to initialize variables and add extra assertions anyway.
Closes 13036. Patches from "teor".
|
|
This function is supposed to construct a list of all the ciphers in
the "v2 link protocol cipher list" that are supported by Tor's
openssl. It does this by invoking ssl23_get_cipher_by_char on each
two-byte ciphersuite ID to see which ones give a match. But when
ssl23_get_cipher_by_char cannot find a match for a two-byte SSL3/TLS
ciphersuite ID, it checks to see whether it has a match for a
three-byte SSL2 ciphersuite ID. This was causing a read off the end
of the 'cipherid' array.
This was probably harmless in practice, but we shouldn't be having
any uninitialized reads.
(Using ssl23_get_cipher_by_char in this way is a kludge, but then
again the entire existence of the v2 link protocol is kind of a
kludge. Once Tor 0.2.2 clients are all gone, we can drop this code
entirely.)
Found by starlight. Fix on 0.2.4.8-alpha. Fixes bug 12227.
|
|
|
|
Found because LibreSSL has OPENSSL_NO_COMP always-on, but this
conflicts with the way that _we_ turn off compression. Patch from
dhill, who attributes it to "OpenBSD". Fixes bug 12602; bugfix on
0.2.1.1-alpha, which introduced this turn-compression-off code.
|
|
|
|
Conflicts:
src/common/include.am
|
|
In the unit tests I want to loop with a delay, but I want less than
a 1 second delay. This, sadly, requires compatibility code.
|
|
When we create a process yourself with CreateProcess, we get a
handle to the process in the PROCESS_INFO output structure. But
instead of using that handle, we were manually looking up a _new_
handle based on the process ID, which is a poor idea, since the
process ID might refer to a new process later on, but the handle
can't.
|
|
This lets us avoid sending SIGTERM to something that has already
died, since we realize it has already died, and is a fix for the
unix version of #8746.
|
|
Also, move 'procmon' into libor_event library, since it uses libevent.
|
|
|
|
|
|
|
|
|
|
This function is supposed to construct a list of all the ciphers in
the "v2 link protocol cipher list" that are supported by Tor's
openssl. It does this by invoking ssl23_get_cipher_by_char on each
two-byte ciphersuite ID to see which ones give a match. But when
ssl23_get_cipher_by_char cannot find a match for a two-byte SSL3/TLS
ciphersuite ID, it checks to see whether it has a match for a
three-byte SSL2 ciphersuite ID. This was causing a read off the end
of the 'cipherid' array.
This was probably harmless in practice, but we shouldn't be having
any uninitialized reads.
(Using ssl23_get_cipher_by_char in this way is a kludge, but then
again the entire existence of the v2 link protocol is kind of a
kludge. Once Tor 0.2.2 clients are all gone, we can drop this code
entirely.)
Found by starlight. Fix on 0.2.4.8-alpha. Fixes bug 12227.
|
|
Fixes bug in b0c1c700114aa8d4dfc180d85870c5bbe15fcacb; bug
12229. Bugfix not in any released Tor. Patch from "alphawolf".
|
|
fixes bug 12139; bugfix on 0.2.5.1-alpha
|
|
Fix for 12115; bugfix on 0.2.5.1-alpha
|
|
(This is how I found out I was trying to test with a kernel too old
for seccomp. I think.)
|
|
This is a minimal set of changes for compilation; I need a more
recent kernel to test this stuff.
|
|
The old cache had problems:
* It needed to be manually preloaded. (It didn't remember any
address you didn't tell it to remember)
* It was AF_INET only.
* It looked at its cache even if the sandbox wasn't turned on.
* It couldn't remember errors.
* It had some memory management problems. (You can't use memcpy
to copy an addrinfo safely; it has pointers in.)
This patch fixes those issues, and moves to a hash table.
Fixes bug 11970; bugfix on 0.2.5.1-alpha.
|
|
|
|
These are needed under some circumstances if we are running with
expensive-hardening and sandbox at the same time.
fixes 11477, bugfix on 0.2.5.4-alpha (where we introduced
expensive-hardening)
|
|
Fixes bug 12032; bugfix on 0.2.5.1-alpha
|
|
None of the things we might exec() can possibly run under the
sanbox, so rather than crash later, we have to refuse to accept the
configuration nice and early.
The longer-term solution is to have an exec() helper, but wow is
that risky.
fixes 12043; bugfix on 0.2.5.1-alpha
|
|
|
|
|
|
|
|
|
|
When running with User set, we frequently try to look up our
information in the user database (e.g., /etc/passwd). The seccomp2
sandbox setup doesn't let us open /etc/passwd, and probably
shouldn't.
To fix this, we have a pair of wrappers for getpwnam and getpwuid.
When a real call to getpwnam or getpwuid fails, they fall back to a
cached value, if the uid/gid matches.
(Granting access to /etc/passwd isn't possible with the way we
handle opening files through the sandbox. It's not desirable either.)
|
|
We'll use these to deal with being unable to access the user DB
after we install the sandbox, to fix bug 11946.
|
|
|
|
|
|
Fix for bug 9781; bugfix on cd05f35d2cdf50 in 0.2.4.2-alpha.
|