Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:04:06Zhttps://gitlab.torproject.org/legacy/trac/-/issues/1299Tor should verify signatures before parsing2020-06-13T14:04:06ZMike PerryTor should verify signatures before parsingRight now Tor parses both consensus documents and router descriptors before verifying their
signature. This exposes us to all sorts of potential MITM tampering and code execution bugs, of which
we have recently had several. Right now, ...Right now Tor parses both consensus documents and router descriptors before verifying their
signature. This exposes us to all sorts of potential MITM tampering and code execution bugs, of which
we have recently had several. Right now, an adversary who finds a parsing exploit needs only to
sign up as a directory mirror, or MITM 0.2.0.x clients that are not using tunnelled directory connections.
Such an adversary can custom-craft payloads based on the fingerprint of the OS of the client that
connects to them, and can also target specific clients for precision attacks.
If we verify signatures before parsing, the adversary loses their ability to target specific clients
by OS or by IP, and can at best publish a malicious router descriptor signed by them to everyone.
This leaves us with a clear audit trail of where the exploit came from, and a record of all such
attempts in the descriptor archives. This would be a considerably better position to be in than
we are now.
[Automatically added by flyspray2trac: Operating System: All]Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/26037DirAuths should check vote signatures before parsing2020-06-13T15:25:29ZIsis LovecruftDirAuths should check vote signatures before parsingteor pointed out that vote parsing occurs before checking the votes signature (both verifying the signature and ensuring that it comes from a known valid directory authority). dgoulet confirmed this is the case:
> See dirvote.c, functi...teor pointed out that vote parsing occurs before checking the votes signature (both verifying the signature and ensuring that it comes from a known valid directory authority). dgoulet confirmed this is the case:
> See dirvote.c, function dirvote_add_vote(). You will notice that the very first thing is parsing the whole thing with networkstatus_parse_vote_from_string(). Now, as far as I can tell, the voter signature check happens in that function. However, by the time we check it out, we've tokenized the votes and parsed _many_ parts of the vote already. (If you look for check_signature_token() in that function).
>
> And then once we are done parsing, we do have a valid signature for the vote which then make us check if we know the authority with trusteddirserver_get_by_v3_auth_digest().
The issue of anyone being able to trigger a hypothetical vulnerability in one of the parsing functions aside, it's also just simply not efficient to do all the parsing work and then chuck the results at the end of `networkstatus_parse_vote_from_string()` if the signature wasn't from a valid sig from a known authority.
This issue has been apparently been present since f4ce7f9c9b4 in tor-0.2.0.3-alpha.Tor: 0.3.5.x-finalSamdneySamdneyhttps://gitlab.torproject.org/legacy/trac/-/issues/26685Add ed25519 id support for the hard-coded fallback and authority lists2020-06-13T15:27:41ZteorAdd ed25519 id support for the hard-coded fallback and authority listsThis is the parent ticket for getting ed25519 id support in Tor's hard-coded directory lists.This is the parent ticket for getting ed25519 id support in Tor's hard-coded directory lists.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/26686Add ed25519 ids to the fallback whitelist2020-06-13T16:06:30ZteorAdd ed25519 ids to the fallback whitelistThe fallback scripts should parse ed25519 ids from the fallback whitelist, and check both the RSA id and ed25519 id.The fallback scripts should parse ed25519 ids from the fallback whitelist, and check both the RSA id and ed25519 id.https://gitlab.torproject.org/legacy/trac/-/issues/26687Output ed25519 IDs in the authority and fallback lists2020-06-13T16:06:30ZteorOutput ed25519 IDs in the authority and fallback listshttps://gitlab.torproject.org/legacy/trac/-/issues/26688Parse ed25519 IDs in the authority and fallback lists2020-06-13T15:27:41ZteorParse ed25519 IDs in the authority and fallback listsTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/32673'buf_read_from_tls()' can return the wrong error code2020-06-13T15:48:52Zopara'buf_read_from_tls()' can return the wrong error codeThe [function](https://gitweb.torproject.org/tor.git/tree/src/lib/tls/buffers_tls.c?id=64d6914232c5ecba2954e9c7a5f6a6b9b8b5fec6#n63) `buf_read_from_tls(...)` returns an integer. This integer can either be `<=0` (in which case it correspo...The [function](https://gitweb.torproject.org/tor.git/tree/src/lib/tls/buffers_tls.c?id=64d6914232c5ecba2954e9c7a5f6a6b9b8b5fec6#n63) `buf_read_from_tls(...)` returns an integer. This integer can either be `<=0` (in which case it corresponds to a `TOR_TLS_` status) or a positive number (in which case it corresponds to the number of bytes read). This return value is [used in](https://gitweb.torproject.org/tor.git/tree/src/core/mainloop/connection.c?id=64d6914232c5ecba2954e9c7a5f6a6b9b8b5fec6#n3749) `connection_buf_read_from_socket()` in a large `switch(result)` statement.
At the beginning of `buf_read_from_tls(...)`, it returns `-1` on the lines:
```
IF_BUG_ONCE(buf->datalen >= INT_MAX)
return -1;
IF_BUG_ONCE(buf->datalen >= INT_MAX - at_most)
return -1;
```
This value of `-1` is the [same as](https://gitweb.torproject.org/tor.git/tree/src/lib/tls/tortls.h?id=64d6914232c5ecba2954e9c7a5f6a6b9b8b5fec6#n48) `TOR_TLS_WANTWRITE`. This causes the switch statement in `connection_buf_read_from_socket()` to interpret the return value as `TOR_TLS_WANTWRITE`, which is not correct for the `buf->datalen >= INT_MAX` bug. I suggest returning `TOR_TLS_ERROR_MISC` instead of `-1`. Note that this would close the connection.
I don't think you'll see incorrect behavior due to this, but it might be a good idea to fix.Tor: 0.4.2.x-finalNick MathewsonNick Mathewson