Opening Firefox v59 keystore with NSS

[Renato Alves]

Hi everyone,

In the past, libnss could be directly initialized by simply pointing the code to a location containing 'cert8.db' and 'key3.db'.
This is the basis of https://github.com/unode/firefox_decrypt a small tool I authored myself with the help of several contributors.

With Firefox 59 key.db and cert.db were modified to use an SQLite format instead of Berkley DB format.
After this change, direct initialization of NSS is no longer possible (tested with older NSS and the latest 3.35).
The latest NSS reports "SEC_ERROR_LEGACY_DATABASE: The certificate/key database is in an old, unsupported format.". The use of "old" in the error message is a little misleading.

With that said, is there any other way to initialize libnss to be able to decode Firefox's profile credentials or is this feature no longer supported?

Many thanks,
Renato

[Hubert Kario]

On Wednesday, 24 January 2018 16:31:26 CET Renato Alves wrote:
> Hi everyone,
>
> In the past, libnss could be directly initialized by simply pointing the
> code to a location containing 'cert8.db' and 'key3.db'. This is the basis
> of https://github.com/unode/firefox_decrypt a small tool I authored myself
> with the help of several contributors.
>
> With Firefox 59 key.db and cert.db were modified to use an SQLite format
> instead of Berkley DB format. After this change, direct initialization of
> NSS is no longer possible (tested with older NSS and the latest 3.35). The
> latest NSS reports "SEC_ERROR_LEGACY_DATABASE: The certificate/key database
> is in an old, unsupported format.". The use of "old" in the error message
> is a little misleading.

yes, the message is misleading

> With that said, is there any other way to initialize libnss to be able to
> decode Firefox's profile credentials or is this feature no longer
> supported?

yes, the DBM database format is deprecated and will be removed in some time.
There are multiple bugs in it that nobody is willing to fix and it is
inherently insecure to use it with multiple applications that modify it at the
same time. SQL database does allow safe parallel accesses and uses maintained
code. Thus the switch.

I'm afraid the tool will have to be modified to support the SQL format now.
As an upside, it will now be safe to use it with Firefox running, provided all
the necessary locking is performed.

--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic

[Renato Alves]

Hi Hubert,

Thanks for the reply.

On 25/01/18 19:10, Hubert Kario wrote:
>> With that said, is there any other way to initialize libnss to be able to
>> decode Firefox's profile credentials or is this feature no longer
>> supported?
>
> yes, the DBM database format is deprecated and will be removed in some time.
> There are multiple bugs in it that nobody is willing to fix and it is
> inherently insecure to use it with multiple applications that modify it at the
> same time. SQL database does allow safe parallel accesses and uses maintained
> code. Thus the switch.

Makes sense. Firefox already uses SQLite for other data-stores anyway...

> I'm afraid the tool will have to be modified to support the SQL format now.
> As an upside, it will now be safe to use it with Firefox running, provided all
> the necessary locking is performed.

My tool doesn't modify data. Up to now there have been no reported
issues related with this use-case but I understand this could be a problem.

Just to clarify, when you say that the tool will have to support the SQL
format, do you mean my tool will have to query the DB itself, obtain
the key pair (private/public) and initialize libnss by some API other
than the one it currently uses? So far all it needed was to call
NSS_Init() [1] and everything would be handled by that call.

[1] - https://github.com/unode/firefox_decrypt/blob/7a536d045c00cc4cd0b94c0d783c39ba1bfd2923/firefox_decrypt.py#L343

On this topic, are you or anyone in the mailing list aware of any
documentation that could help transitioning to the new API? At this
point I'm still unsure about which method's I'd have to call for proper
initialization with the 'new' interface.

Thanks and cheers,
Renato

[Hubert Kario]

I thought that you were using it as DBM database, without help of NSS.
If you use nss library, specifying the path to the folder with databse with
"sql:" as a prefix should be enough.

With certutil it looks like this:

certutil -L -d sql:/home/user/.pki/nssdb

[Renato Alves]

On 25/01/18 20:58, Hubert Kario wrote:
> I thought that you were using it as DBM database, without help of NSS.
> If you use nss library, specifying the path to the folder with databse with
> "sql:" as a prefix should be enough.
>
> With certutil it looks like this:
>
> certutil -L -d sql:/home/user/.pki/nssdb

Thanks, this worked wonderfully [1]. It's even backwards compatible.

[1] https://github.com/unode/firefox_decrypt/commit/089e1df285bc6619c2acebcedacba76070286981#diff-1414aa7f803aa0fc1f720d9ebf9dbb86R343

Couldn't ask for anything smaller than that :)

Cheers and thanks again,
Renato