1413994 - Deleting a private key stored in the dbm format file (key3.db) will not remove it from the file.

Status: NEW

(NSS :: Libraries, defect, P5)

Description

[Finn Nielsen]

Steps to Reproduce:
I imported a P12 file in firefox's certificate manager and deleted it but the key3.db still contains the private key.

The same steps can be reproduced with pk12util and certutil (mozilla-nss-tools) on the command line:

    profile=~/.mozilla/firefox/t1nbcz1v.private_key_in_db_test2017
    pk12util -i firefoxdb_keytest_2017.p12 -d $profile -W foobar
    certutil -d $profile -K
    hexdump $profile/key3.db > key3_before_deletion
    certutil -d $profile -F -n "FirefoxDB Keytest 2017"
    certutil -d $profile -K
    hexdump $profile/key3.db > key3_after_deletion

    diff key3_before_deletion key3_after_deletion

Actual Results:
The hexdumps of the key3.db before and after deleting the certificate showed a difference of only 6 bytes. This looks like the key is only marked as deleted. (The certificate manager does not display the certificate any more.)

Expected Results:
The private key should have been completely deleted resulting in a much greater diff.

Comment 1

[Sylvestre Ledru [:Sylvestre]]

[Tracking Requested - why for this release]:
We might want to fix that in the 58 cycle.

Comment 2

[Kai Engert (:KaiE:)]

Please note that a fix will require a code change at the NSS library level.

Firefox 58 uses NSS 3.34, and has already been released.
This means, a fix for Firefox 58 would require a NSS 3.34.x release and uplifting it to Firefox 58 during the beta period.

We should start to work on a fix on NSS trunk, and once fixed for NSS 3.35 or later, then we can make an assessment about uplifting it into NSS 3.34.x/Firefox 58.

Comment 3

[Kai Engert (:KaiE:)]

Also note that Firefox 58 will likely no longer use the dbm NSS database file format, but will use the newer sql file format.

The bug reported here is specific to the dbm database format, so Firefox 58 would no longer have this bug in the default configuration.

Comment 4

[Sylvestre Ledru [:Sylvestre]]

OK, no need to worry then. Thanks!

Comment 5

[Finn Nielsen]

Will Firefox 58 upgrade existing databases to the new file format? If the old files are kept the bug will persist until the user manually deletes the key3.db.

Comment 6

[Kai Engert (:KaiE:)]

(In reply to Finn Nielsen from comment #5)
> Will Firefox 58 upgrade existing databases to the new file format?

Yes.

On first (write) access, the database files will be automatically converted.
The old files are kept (and ignored).

Comment 7

[Kai Engert (:KaiE:)]

(In reply to Finn Nielsen from comment #5)
> If the
> old files are kept the bug will persist until the user manually deletes the
> key3.db.

Even if we fixed this bug for the old dbm storage, the bug would persist for all old deletions.
The fix would only help new deletions performed with the fixed software.

A full fix would require a mechanism that rewrites the old key3.db in a way that purges all empty sections.

Comment 8

[Robert Relyea]

Kai, I'm not sure where this text should go. I'm adding to to the comment so it can be found and put in the correct place.


Deleting Keys in DBM databases.

If your application used the DBM database, which is the default database until recently, it is possible that any keys you delete from that database may still exist in the file. That is because the dbm code used to support that database may just mark entries as 'deleted' and not actually remove them from the disk.

If you need to make sure that the key is gone, the best way of doing this (short of completely overwriting the database) is to change the password on the database. You can change the password to the same as your old password. This will create a new salt value in the database, and thus a new key, which will be used to reencrypt all the entries in the database. Since the deleted key will not be visible, it won't get reencrypted. The old salt is overwritten with the new salt so the old key can't be recovered even with the password for the database..

The old dbm database is being phased out, there will be no attempt to try to change the delete code to work around the issue.

You can change the password in the database in an application with the following call:

PK11_ChangePW(slot, oldpw, newpw). You can get the slot from the key before you delete itw

You can also use certutil:

certutil -W -d {database}

Inside Firefox, you can go to preferences->Security. If 'use a master password' is checked, select 'Change Master Password...'. if it's not check, check it and set a password, then uncheck the box.