Resolve TROVE-2020-003: crash adding bad ed25519 HSv3 private key from controller
This bug is an assertion failure that can only be triggered by an attacker with access to the user's controlport: if they use ADD_ONION to pass in an invalid ed25519 key, then Tor will exit.
Here is asn's analysis of the issue:
================================================================================ Analysis of TROVE-2020-003 ================================================================================ Summary ================================================================================ The issue at hand is that hs_build_address() can crash with an assert failure if called with an "invalid" ed25519 public key as its 'key' argument. Usually that function is only called with valid public keys, but after the introduction of the ADD_ONION control port feature and the hs_service_add_ephemeral() function, it can now be called with an invalid public key and cause an assert crash. Tor considers an ed25519 public key to be "invalid" when it has a torsion component (see [TORSION-REFS] in rend-spec-v3.txt) so that phishing attackers cannot generate equivalent onion addresses for a normal onion address. This is a validation step that is usually not required for normal ed25519-based protocols, but it's actually necessary for the security of onion addresses or in any other place where keys or signatures are used as identifiers and security relies on their uniqueness. The validating function is ed25519_validate_pubkey() and it's currently used in two cases: 1) for onion address validation, so that attackers cannot create equivalent sets of onion addresses 2) when dirauths validate relay ed25519 keys, for reasons unclear to me (perhaps this check is not needed) Impact ================================================================================ The impact of this bug is a local denial-of-service attack to Tor through an assert-failure. The particular ADD_ONION attack vector can only be triggered by an attacker who has access to the control port which assumes a local attacker. Also an attacker who has access to the control port can do various other modifications to Tor that will result in loss of security. This is the reason this bug is marked as 'low' severity. Fix ================================================================================ Given that ed25519 public key validity checks are usually not needed and (so far) they are only necessary for onion addesses in the Tor protocol, we decided to fix this specific bug instance without modifying the rest of the codebase (see below for other fix approaches). In our minimal fix we check that the pubkey in hs_service_add_ephemeral() is valid and error out otherwise. This will fix the issue in the current codebase but it doesn't solve it in the future if a new feature comes in which tried to do something like ADD_ONION, or if a new feature comes out which tries to use ed25519 in a non-standard and dangerous way. Considerations for the future ================================================================================ ed25519 signature and public key malleability is a complex topic that protocol designers must be aware of when using ed25519 in non-standard ways in the protocol. In our case, we got bitten by passing ed25519 *private* keys around, but there are other theoretical cases where this can bite us. Hence, protocol designers and reviewers who work with ed25519 should be aware of such threats when creating new protocols. In the future, we should consider moving to signature schemes based on Ristretto (or others) which do not need additional optional key validation. Other fix approaches ================================================================================ Here are some other fix approaches I ended up not taking: 1) Check validity in ed25519_public_key_generate() One possible fix would be to patch ed25519_public_key_generate() so that it doesn't return "invalid" public keys. However, ed25519_validate_pubkey() is not cheap (it does a scalar mult and a point compression) and it's almost never needed, so we would make this validation optional and only enable it when it's needed. The problem here is that this is gonna complicate the interface of ed25519_public_key_generate() for everyone, and also it almost never makes sense to use the validation feature so developers will always be confused on whether they should use it or not. For reference, see how ed25519-dalek has the optional verify_strict() function which is not clear when should be used by developers . 2) Enforce validity in ed25519_public_key_generate() Another approach would be to enforce that public keys created with ed25519_public_key_generate() are valid by clamping the secret key before producing the public key. Clamping is not expensive so this would not be too bad for performance. I actually tried to implement this but the blinded public key tests immediately broke: it seems like there are issues with clamping and hierarchical key derivation that would not allow us to do this . Furthermore, doing this would change our ed25519 behavior in a non-standard way. 3) Fix this particular HSv3 bug (in hs_build_address()) Another fix would be to patch just hs_build_address() and make sure that it fails if the resulting address is not valid. The problem here is that this will complicate the interface of hs_build_address() which is normally called with well behaving keys and is only called with a bad key in the case of ADD_ONION. The callers would have to check the retval for no gain, and the end result would be equal to the fix approach we took. Further investigation ================================================================================ As part of our investigation for this bug, we did the following additional digging: - Audited all the places where hs_build_address() is called We audited all the places where hs_build_address() is called to see if any of them might be called with invalid pubkeys but it seems like the only vulnerable place is the bug above related to ADD_ONION. All other calls of hs_build_address() are either using the self-generated service public keys, or in the client case getting them directly from the HS identifier where the public key has been explicitly checked for validity during the SOCKS phase in connection_ap_handshake_rewrite_and_attach() with parse_extended_hostname(). XXX Do you want me to make a branch with the various call sites annotated with why I think they are innocent? - Audited all the places where we get ed25519 private keys from foreign sources Tor mostly loads self-generated ed25519 private keys from files, or generates them itself (e.g. in the case of blinded keys). The only place where an ed25519 private key is loaded from a non-local source is the bug in question above using ADD_ONION. - Audited all the places where we get x25519 private keys from foreign sources In general, x25519 keys should not need validation like we do for ed25519 keys . Still, we decided to take a look at whether we load any x25519 private keys from non-local sources as part of our investigation. Tor usually loads pre-generated x25519 keys from file, or generates them itself. However, in the HSv3 client authorization feature we can get an x25519 privkey from the control port through the ONION_CLIENT_AUTH_ADD command (in handle_control_onion_client_auth_add()). However, we never convert that key to a pubkey, as it always lives in hs_client_service_authorization_t as a secret key. Also, when we actually do use that secret key in build_descriptor_cookie_keys() the x25519 module is responsible for doing the necessary tweaks to make it well formed (see how curve25519_donna() does the necessary bit transformations on the 'secret' key). : https://github.com/dalek-cryptography/ed25519-dalek#the-verify_strict-function : https://moderncrypto.org/mail-archive/curves/2017/000858.html : https://lists.torproject.org/pipermail/tor-dev/2017-April/012213.html