- CNA ID
Key protection settings not copied after unprotect action
- CVE ID
- CVSS 3.1 score
- CVSS 3.1 vector
- Affected vendors
- Affected products
RNP, versions prior to 0.15.1
A key decrypted through
rnp_key_unprotect will remain unprotected
after after a subsequent call of
This issue was discovered in Thunderbird versions 78.8.1 to 78.10.1,
where it was found that a key decrypted through
will remain unprotected after after a subsequent call of
In RNP versions prior to 0.15.1, calling
rnp_key_protect on a
key that was “unprotected” by
rnp_key_unprotect will not result
in a re-protected key, as:
rnp_key_unlockis designed to temporarily decrypt secret key data to make the secret key usable. This call does not overwrite key protection settings.
rnp_key_unprotectdecrypts key data and overwrites key protection settings, and stores key data in unprotected form.
In the aforementioned scenario, due to the call sequence of calling
rnp_key_unprotect and then
rnp_key_protect, the key protection
settings were not properly copied within RNP, leaving key material in the clear.
This would not happen if the key underwent
From RNP 0.15.1 and onwards
rnp_key_protect implements re-protection
for keys that have been “unprotected” by
Upgrading to RNP 0.15.1 fixes this issue. If unprotected keys have been saved outside of RNP, a re-protection step needs to apply.
For Thunderbird users, auto-re-protection has been implemented in the latest release. Please refer to Bugzilla Bug 1710290 for more details.
Kai Engert (Mozilla) and Thunderbird users.