nssckbi not loaded without explicit configuration in secmod db

VERIFIED FIXED in 3.6

Status

P1
normal
VERIFIED FIXED
17 years ago
14 years ago

People

(Reporter: nelson, Assigned: rrelyea)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

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.
(Reporter)

Comment 1

17 years ago
This needs to work in 3.4.  
Priority: -- → P1
Target Milestone: --- → 3.4
(Assignee)

Comment 2

17 years ago
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

17 years ago
Assigned the bug to Bob.
Assignee: wtc → relyea
(Reporter)

Comment 4

17 years ago
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.
(Assignee)

Comment 5

17 years ago
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.
(Reporter)

Comment 6

17 years ago
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.
Priority: P1 → P2

Comment 7

17 years ago
Should we remove the readOnly flag and close this bug?

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

Comment 8

17 years ago
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

17 years ago
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.
(Assignee)

Comment 10

17 years ago
Created attachment 71974 [details] [diff] [review]
Load builtins even when opening read only
(Assignee)

Comment 11

17 years ago
Wan-Teh: Yes, that is why I'm relunctant to make it a default.
(Reporter)

Comment 12

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

Comment 13

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

r=wtc.

Bob, have you tested this patch?
Attachment #71974 - Flags: review+
(Assignee)

Comment 14

17 years ago
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

17 years ago
Changed the QA contact to Bishakha.
QA Contact: sonja.mirtitsch → bishakhabanerjee
(Assignee)

Comment 16

17 years ago
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.
Target Milestone: 3.4 → 4.0

Updated

17 years ago
Keywords: nsbeta1

Comment 17

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

Comment 18

17 years ago
Created attachment 89573 [details] [diff] [review]
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).

Updated

17 years ago
Priority: P2 → P1
Target Milestone: 4.0 → 3.6
(Assignee)

Comment 19

16 years ago
Closing bug since the patch is checked in the tip.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 20

16 years ago
Verified that the fix was checked into the tip in rev. 1.48
of nssinit.c.
Status: RESOLVED → VERIFIED
(Reporter)

Comment 21

14 years ago
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.
(Assignee)

Comment 22

14 years ago
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
(Reporter)

Comment 23

14 years ago
So, Bob, please add a comment here stating what symptom you fixed when 
this bug was resolved.  
You need to log in before you can comment on or make changes to this bug.