128290 - nssckbi not loaded without explicit configuration in secmod db

Status: VERIFIED FIXED

(NSS :: Libraries, defect, P1)

Description

[Nelson Bolyard (seldom reads bugmail)]

Using NSS 3.4 trunk tip, create new cert, key and secmod dbs using the
command

mkdir /tmp/newdb
certutil -N -d /tmp/newdb

Then attempt to connect to an SSL server whose cert was issued by a well
known CA, whose CA cert is in nssckbi, e.g. www.microsoft.com.
The command I used was

strsclnt -c 2 -d /tmp/newdb -t 1 -v www.microsoft.com

The expected result is that two https connections will be done.
The first will do a full RSA handshake, and the second will do a 
restart handshake.  

But the actual result is 

strsclnt: Subject: CN=www.microsoft.com, OU=mscom, O=Microsoft, L=Redmond, 
ST=washington, C=US
strsclnt: Issuer : OU=Secure Server Certification Authority, O="RSA Data 
Security, Inc.", C=US
strsclnt: -- SSL: Server Certificate Invalid, err -8179.
        Peer's Certificate issuer is not recognized.
strsclnt: PR_Write returned error -8179:
        Peer's Certificate issuer is not recognized.


This has been observed on 3 different platforms.  When he tested it on 
Linux, Ian observed that nssckbi was not being loaded.  He also tried
copying nssckbi into the directory where secmod.db is located, but still
nssckbi was not loaded.  Finally he configured secmod.db explicitly to
load nssckbi, and then it worked.  

I believe it should not be necessary to explicitly put nssckbi into secmod.db.

Further, I believe that if nssckbi is in the same directory where the other
nspc and nss DLLs are located, NSS should be able to find it there and load
it.  That is, it should not be nececssary to copy nssckbi to the secmod.db
directory to load it.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

This needs to work in 3.4.  

Comment 2

[Robert Relyea]

nssckbi only gets automatically loaded when  1) it's in the appropriate
directory, 2) the application openned the databases ReadWrite, and 3) a built-in
module has not already been loaded In this case it gets loaded and inserted into
secmod.db

It also gets loaded if it is already in secmod.db

The following should work:

mkdir /tmp/newdb
cp libnssckbi.so /tmp/newdb
certutil -N -d /tmp/newdb

strsclnt -c 2 -d /tmp/newdb -t 1 -v www.microsoft.com

If you do the copy after the certutil -N, strsclnt won't be able to add the
built-ins to the secmod.db.

Question: should we attempt to load the built-ins even if we can't add them to
secmod.db? We could do that by changing the if statement in nss_Init from:

if ((!readOnly) && (!noModDB) && (!noCertDB) && (!noRootInit))

to

if ((!noModDB) && (!noCertDB) && (!noRootInit))

bob

Comment 3

[Wan-Teh Chang]

Assigned the bug to Bob.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

IMO, yes, we should attempt to load the builtins module even if secmod.dh
is RO.

Having to have the dll in the same directory where the secmod.db file 
lives seems to violate the idea of separating trusted code files from 
user-modifiable data files.

In system security terms, All parts of the TCB should (potentially) be 
kept in a directory where the user does not have write access.  


Is there a way to get nssckbi loaded without copying it to the secmod.db
directory and without expicitly using modutil to config it into secmod.db??
IMO, there should be.

Comment 5

[Robert Relyea]

If you can tell me how to do it.

This has been the semantic since NSS 3.1. Most applications either copy the
built-ins to the correct location, or explicitly load the builtins on their own.
The latter gives the apps control over where they install the libraries.

The problem is there was no good way to find the path for where libnssckbi.so
was supposed to be. The only path we had available was the configDir path.

Removing the readonly flag seems reasonable for NSS 3.4.

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

At Bob's suggestion, I created a secmod.db file that had the nssckbi 
module declared in it, without any path.  That is, the file name is 
just "nssckbi.dll".  Bob said that would find the dll in the PATH, 
and indeed, it did.  So, I can have a single fixed secmod.db file that
will work for all apps on WinCE, and that is enough for now.  

Lowering to P2.

Comment 7

[Wan-Teh Chang]

Should we remove the readOnly flag and close this bug?

Is there anything else we need to do about this bug?

Comment 8

[Robert Relyea]

After talking with nelson, it would be possible to load nssckbi from the path if
we don't find it in the configdir, but I'm worried that this would be a semantic
change which could affect existing 3.x products expecting the current behaviour.
 
I'll attach a patch for the removed flag.

Comment 9

[Wan-Teh Chang]

Picking up nssckbi.dll from the path can be dangerous.
If someone adds a different nssckbi.dll to your PATH,
you will unknowingly pick it up.

Comment 10

[Robert Relyea]

Attachment: Load builtins even when opening read only

Comment 11

[Robert Relyea]

Wan-Teh: Yes, that is why I'm relunctant to make it a default.

Comment 12

[Nelson Bolyard (seldom reads bugmail)]

The same argument could be made for any part of NSS, no?  
All the software in your PATH must be "trusted", IINM.

Comment 13

[Wan-Teh Chang]

Comment on attachment 71974 [details] [diff] [review]
Load builtins even when opening read only

r=wtc.

Bob, have you tested this patch?

Comment 14

[Robert Relyea]

I've ran our system tests on the patch to determine it does not cause any
obvious regression, but it has not been tested for the functionality it is
supposed to provide.

Comment 15

[Wan-Teh Chang]

Changed the QA contact to Bishakha.

Comment 16

[Robert Relyea]

The only remaining issue in this bug is the path search issue, and that seems to
be a semantic change that could upset existing applications. Moving to 4.0 where
we can make these kinds of semantic changes.

Comment 17

[Wan-Teh Chang]

*** Bug 154736 has been marked as a duplicate of this bug. ***

Comment 18

[Wan-Teh Chang]

Attachment: Patch for NSS_Init

Turns out that the previous patch alone is not enough to
fix the bug.  NSS_Init is not loading nssckbi.dll
automatically because it incorrectly passes PR_TRUE as
the noRootInit argument to nss_Init.

This bug was most likely introduced in NSS 3.4 Beta 1,
when the noRootInit argument to nss_Init was added.

This bug has been fixed on the tip (3.6).

Comment 19

[Robert Relyea]

Closing bug since the patch is checked in the tip.

Comment 20

[Wan-Teh Chang]

Verified that the fix was checked into the tip in rev. 1.48
of nssinit.c.

Comment 21

[Nelson Bolyard (seldom reads bugmail)]

This bug has been marked fixed, but the symptom originally described is 
still reproducible in NSS 3.10.  This is now reportedly an issue for RedHat, 
and has been discussed in the newsgroup.

Bob/Wan-Teh, please kindly add a comment here stating what other symptom 
you fixed when this bug was closed.  
Perhaps a separate bug should have been filed for that other symptom, 
whatever it was, rather than marking this bug fixed.  

Now, perhaps a new bug should be created that restates the original issue,
and this bug (128290) should be modified to describe the symptom that was
fixed for NSS 3.6.

Comment 22

[Robert Relyea]

Trying to do automatic loading of libnssckbi.so in NSS would only make the
redhat case worse. The problem would not only be trying to determine where
libnssckbi.so is, but trying to determine the correct libnssckbi.so (32 or 64 bit).

On top of that, it's looking like for a number of interesting applications, we
may not want to load libnssckbi.so at all, so making NSS autoload libnssckbi is
probably going the wrong way.

Ideally the application should load the version of libnssckbi.so that it wants
to use, and we shouldn't do any autoloading from NSS.

bob

Comment 23

[Nelson Bolyard (seldom reads bugmail)]

So, Bob, please add a comment here stating what symptom you fixed when 
this bug was resolved.