I've read this a few times now and, like Kai, I'm having trouble understanding the issue. I apologize for what may appear as nits, but in a discussion like this it is important to be precise and use accepted terminology.
(In reply to Wayne Mery (:wsmwk) from comment #0)
It was found that Thunderbird allows importing primary keys and subkeys that are not bound to a valid cryptographically secure signature.
What does this mean? In OpenPGP primary keys and subkeys are not bound to signatures. A signature binds a component (e.g., a subkey or a User ID) to the primary key. Slightly simplified, a certificate is a primary key (which solely determines the certificate's fingerprint), binding signatures made by the primary key, and components for which there are valid binding signatures made by the primary key. The validity of a primary key is determined by the trust model (web of trust, direct trust, TB's "key acceptance"). The validity of a component is derived from any signatures that the primary key makes over the component; the primary key is the certificate's trust root. In other words, if there is a valid binding signature over a subkey made by the primary key, the subkey is de jure associated with the primary key; a signature is the sufficient and necessary proof that the entity that controls the key (certificate plus secret key material) wants the component to be part of the certificate.
Note: subkeys cannot stand alone.
Additionally, Thunderbird automatically imports detected, attached PGP primary keys with an already trusted fingerprint, as it has an extended expiry time. This introduces the risk of attackers obtaining a primary key with an extended or unset expiry time of a trusted person, while it has not yet been imported into the PGP key ring of the victim.
I don't understand what is being claimed here :/.
Why is the primary important here: "PGP primary keys"? Is the implication that Thunderbird is ignoring the rest of the certificate?
What is a trusted fingerprint? I think what is meant is an authenticated certificate.
What does it mean to have an extended expiry time? Some component has a new binding signature, whose expiration time has been extended?
What does "while it has not yet been imported" mean?
It sounds like: "Thunderbird automatically imports certificates under certain conditions. An attacker may automatically import a new version of the certificate, and a victim may not." Please confirm or correct my understanding. If I understood correctly, what's the risk there?
The attackers can abuse this by adding a malicious subkey, which has been used by Thunderbird for email encryption, signature verification and key certification.
Guessing again: "An attacker can add an invalid subkey to a certificate, and the victim's Thunderbird may import it, and use it"
Although the subkey is flagged as invalid by RNP, it is silently accepted and imported by Thunderbird as soon as the user opens the attacker’s mail.
Subkeys are not independent objects. If a subkey is not bound to a primary key via a valid binding signature, then the OpenPGP implementation should ignore it. If it doesn't, then the OpenPGP implementation is broken.
Justus reported this to RNP on July 13, 2018:
Critical vulnerability in RNP, Ribose's fork of Netpgp.
RNP fails to validate subkey bindings, allowing malicious parties to
add or replace subkeys, even if the authenticity of the key is
verified by comparing fingerprints, or other means like the web of
trust. This allows an attacker that is able to control a victims
network traffic to read messages encrypted using RNP.
OpenPGP implementations need to aquire the transferable public key
(TPK) of the peers one wants to communicate with. This happens when
establishing a new peer, and periodically to refresh ones copy of the
TPK to get new keys, certificates, or revocations.
If an attacker controlling the victims network traffic is able to
modify the TPK in flight. Due to the missing signature verification,
she can replace the encryption subkey present in the TPK with her own.
Key verification, like comparing key fingerprints, is ineffective
because it is done on the primary key, which is not changed.
If the victim now encrypts a message using the attackers encryption
key, the attacker can intercept the message, read it, re-encrypt it
with the original encryption key, and send it to the intended
recipient. The confidentiality of the message has been compromised.
Like subkey bindings, the following signatures are likely also
affected: user-id bindings, user-attribute bindings, revocations of
Ronald acknowledged the issue and indicated that they would fix it by the end of the week. As far as I know, a report about the vulnerability was never published.
Anyway, that RNP flags a subkey as invalid is good. That Thunderbird has to check if the subkey is valid before using it is deeply dangerous. A context that requires a key should only accept a valid key. Or, in the very least, be opt-in instead of opt-out.
Thunderbird should aggressively import certificates. It should be up to the OpenPGP implementation, in this case RNP, to authenticate the components using the primary key as the trust anchor.
Thunderbird should not treat the keyring as a curated keyring; it is a cache. If a binding between an identifier (email) and a certificate can be authenticated by the trust model, then the certificate should be used. Otherwise, it should be ignored.
It is advised that the validity of the PGP keys returned from the RNP library is respected by Thunderbird and actions ensue accordingly.
If RNP exposes invalid subkeys to Thunderbird, then it is indeed Thunderbird's responsibility to add a check that they are valid before using them. But, I don't see what that has to do with importing invalid components, and why that is risky, or what expiry has to do with any of this.
Additionally, Cure53 recommends for trusted primary keys not getting automatically imported. Instead, the user should be informed and asked about importing the new key. It is crucial to alert the user about every new subkey and user-identity which is about to be newly trusted.
This is horribly, horribly wrong. Do not ask the user about importing new certificates. Subkeys and User IDs are authenticated via binding signatures. The user cannot make an informed choice. Do not make the OpenPGP support less usable then it already is.
Finally, it's disappointing that no proof of concept was provided.