NSS: Potential problem with sqlite key4.db and symmetric keys (SDR), introduced between NSS 3.36 and NSS 3.44
Categories
(NSS :: Libraries, defect, P2)
Tracking
(Not tracked)
People
(Reporter: KaiE, Assigned: KaiE)
References
Details
We've two Thunderbird bug reports, with similar confusing symptoms.
After a migration from TB 60.x to TB 68.x, which is equivalent to a migration from NSS 3.36.x to NSS 3.44.x, the application's secret decoder ring (SDR) was no longer able to decrypt the saved logins, and consequently connections to the configured mail server failed.
The user has never used versions before Thunderbird 60, and doesn't have a key3.db file in their directory, so it cannot be related to the dbm->sql migration issue.
I can only speculate, but my best theory is that the key4.db file is corrupted, and somehow the older NSS was more lenient with tolerating a corruption, while the newer NSS cannot use the old database (or affected entries) any more.
Or maybe there are multiple symmetric keys inside the database, and newer NSS decides to use a different key?
My question to you:
Can you think of any code modifications that were made between the mentioned NSS versions, which could potentially have this kind of effect?
(If the problem isn't just a file corruption, but a bug, then Firefox users would be equally affected, but might notice it less frequently. A password no longer saved for a website is probably less noticeable than the stored password for a configured email account.)
Any thoughts welcome. We haven't yet triggered a major upgrade of all TB 60.x users to TB 68, so we don't know yet is this is a widespread issue, or just a coincidence that two users had (apparently) the same problem.
|
||
Comment 1•6 years ago
|
||
Kai, at least for me, I cannot remember something that could cause that between these versions.
But I know that lately the embeded SQLite in NSS was updated to the 2019 version in BUG 1550636.
The next release is coming soon. Maybe you can test again with version 3.46.
I would suggest, if possible, try to validate the integrity of this DB with certutil.
|
||
Comment 2•6 years ago
|
||
I spent some time yesterday scrubbing through the changelogs since 3.36 and didn't find any smoking guns, Kai. This might need us to forensically analyze a "corrupted" database -- not an easy path to navigate.
Marcus' suggestion of dumping data with various certutil commands which can be more easily sanitized is probably the place to start.
|
|
||
Updated•6 years ago
|
|
|
||
Comment 3•6 years ago
|
||
Also, would bug 1517188 help with this?
|
Assignee | |
Comment 4•6 years ago
|
||
Thanks a lot for checking.
It now seems we have only one user out of several bug reports who experienced a key loss issue.
|
|
Assignee | |
Comment 5•6 years ago
|
||
Looks like this was a false alert. Although the user could no longer decrypt some passwords, the reported failure wasn't caused by missing passwords, but by other manual configuration changes made by the user...
We still don't understand why some old passwords could no longer be decrypted, but it could be explained by a lost key4.db file.
Closing for now. I'll reopen should we get more reports of the same type.
Description
•