Opening Firefox v59 keystore with NSS

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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


_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Opening Firefox v59 keystore with NSS

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
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Opening Firefox v59 keystore with NSS

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


_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Opening Firefox v59 keystore with NSS

Hubert Kario
On Thursday, 25 January 2018 20:01:12 CET Renato Alves wrote:

> 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/7a536d045c00cc4cd0b94c0d783c3
> 9ba1bfd2923/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.
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

--
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
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Opening Firefox v59 keystore with NSS

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


_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security

signature.asc (849 bytes) Download Attachment