Bug 633043 - nss trusts CAs it shouldn't
Summary: nss trusts CAs it shouldn't
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: nss
Version: 13
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Elio Maldonado Batiz
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
: 636859 (view as bug list)
Depends On:
Blocks: 643134
TreeView+ depends on / blocked
 
Reported: 2010-09-12 15:15 UTC by David Woodhouse
Modified: 2011-03-07 20:56 UTC (History)
7 users (show)

(edit)
Clone Of:
: 643134 (view as bug list)
(edit)
Last Closed: 2011-03-01 04:23:02 UTC


Attachments (Terms of Use)
script to reproduce the bug / verify fix (874 bytes, text/plain)
2010-10-31 23:43 UTC, Elio Maldonado Batiz
no flags Details
script to reproduce the bug / verify fix (1012 bytes, text/plain)
2010-11-04 15:36 UTC, Elio Maldonado Batiz
no flags Details
cert in DER used for testing (1.51 KB, application/octet-stream)
2010-11-24 18:05 UTC, Elio Maldonado Batiz
no flags Details
Fix to honor user's preferences regarding trust (5.29 KB, patch)
2011-01-22 19:28 UTC, Elio Maldonado Batiz
no flags Details | Diff
to reproduce / verify fix - with a few more steps (1.15 KB, application/x-sh)
2011-01-23 22:40 UTC, Elio Maldonado Batiz
no flags Details
Updated patch per upstream review requests (7.44 KB, patch)
2011-01-26 18:48 UTC, Elio Maldonado Batiz
no flags Details | Diff
V3: Updated patch per additional upstream review requests (7.58 KB, patch)
2011-01-27 03:17 UTC, Elio Maldonado Batiz
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Mozilla Foundation 595988 None None None Never
Red Hat Bugzilla 636859 None None None Never

Internal Trackers: 636859

Description David Woodhouse 2010-09-12 15:15:03 UTC
[dwmw2@i7 nssdb]$ sudo setup-nsssysinit.sh off
[dwmw2@i7 nssdb]$ sudo certutil -d sql:/etc/pki/nssdb -L

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

Intel_External_Basic_Issuing_CA_3A_20060322.crt              CT,C,C
Intel_External_Basic_Issuing_CA_3A_20090515.crt              CT,C,C
Intel_External_Basic_Issuing_CA_3B_20060322.crt              CT,C,C
Intel_External_Basic_Issuing_CA_3B_20090515.crt              CT,C,C
Intel_External_Basic_Policy_CA_20060216.crt                  CT,C,C
Intel_Intranet_Basic_Issuing_CA_1A_20050524.crt              CT,C,C
Intel_Intranet_Basic_Issuing_CA_1A_20060524.crt              CT,C,C
Intel_Intranet_Basic_Issuing_CA_1A_20090515.crt              CT,C,C
Intel_Intranet_Basic_Issuing_CA_1B_20050610.crt              CT,C,C
Intel_Intranet_Basic_Issuing_CA_1B_20060524.crt              CT,C,C
Intel_Intranet_Basic_Issuing_CA_1B_20090515.crt              CT,C,C
Intel_Intranet_Basic_Issuing_CA_2A_20060524.crt              CT,C,C
Intel_Intranet_Basic_Issuing_CA_2A_20090515.crt              CT,C,C
Intel_Intranet_Basic_Issuing_CA_2B_20060524.crt              CT,C,C
Intel_Intranet_Basic_Issuing_CA_2B_20090515.crt              CT,C,C
Intel_Intranet_Basic_Policy_CA_20050518.crt                  CT,C,C
Intel_Intranet_Basic_Policy_CA_20060524.crt                  CT,C,C
Intel_Root_CA_20050518.crt                                   CT,C,C
[dwmw2@i7 nssdb]$ sudo certutil -d sql:/home/dwmw2/.pki/nssdb -L

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

CAcert Class 3 Root - Root CA                                ,,   
[dwmw2@i7 nssdb]$ /usr/lib64/nss/unsupported-tools/tstclnt -h twosheds.infradead.org -p 993 -d sql:/etc/pki/nssdb
tstclnt: read from socket failed: Peer's Certificate issuer is not recognized.
[dwmw2@i7 nssdb]$ /usr/lib64/nss/unsupported-tools/tstclnt -h twosheds.infradead.org -p 993 -d sql:/home/dwmw2/.pki/nssdb
tstclnt: read from socket failed: Peer's Certificate issuer is not recognized.


All is well...

Comment 1 David Woodhouse 2010-09-12 15:15:28 UTC
[dwmw2@i7 nssdb]$ sudo setup-nsssysinit.sh on
[dwmw2@i7 nssdb]$ /usr/lib64/nss/unsupported-tools/tstclnt -h twosheds.infradead.org -p 993 -d sql:/home/dwmw2/.pki/nssdb
tstclnt: read from socket failed: Peer's Certificate issuer is not recognized.
[dwmw2@i7 nssdb]$ /usr/lib64/nss/unsupported-tools/tstclnt -h twosheds.infradead.org -p 993 -d sql:/etc/pki/nssdb
subject DN: CN=twosheds.infradead.org
issuer  DN: CN=CAcert Class 3 Root,OU=http://www.CAcert.org,O=CAcert Inc.
0 cache hits; 1 cache misses, 0 cache not reusable
0 stateless resumes
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE AUTH=PLAIN] Dovecot ready.


WTF?

Comment 2 David Woodhouse 2010-09-12 15:16:04 UTC
[dwmw2@i7 nssdb]$ certutil -d sql:/etc/pki/nssdb -L

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

CAcert Class 3 Root - Root CA                                CT,C,C

Comment 3 David Woodhouse 2010-09-12 15:22:44 UTC
Throwing away the contents of /etc/pki/nssdb makes it go away. And this makes it come back:
[root@i7 nssdb]# certutil -d sql:/etc/pki/nssdb -A -i ~dwmw2/class3.crt -n class3 -t TC,TC,TC
[root@i7 nssdb]# certutil -d sql:/etc/pki/nssdb -D -n class3

Comment 4 David Woodhouse 2010-09-12 15:28:18 UTC
It looks like NSS is using the trust bits from /etc/pki/nssdb for the certificate, instead of allowing them to be overridden by the bits in $HOME/.pki/nssdb. Surely that's the wrong way round -- the user should be able to override the trust settings inherited from /etc/pki/nssdb?

And it's even *worse* that this continues to happen even after the certificate is supposed to have been *removed* from the database in /etc/pki/nssdb :)

Comment 5 David Woodhouse 2010-09-22 13:42:35 UTC
Should we assign a CVE for this? Trusting a CA that the admin has *removed* from the trust database is worthy of a CVE, isn't it?

Comment 6 Tomas Hoger 2010-09-23 13:19:57 UTC
Let's start by not mixing all issues together.  Reading this report, I believe the primary issue here is that when combining system and user nssdb data together, NSS may end up using trust flags from *deleted* system nssdb entry and certificate from *untrusted* user nssdb entry and trust in the combination of the two.  It may be better to keep concerns regarding which trust flags should trump the other aside for now.

I believe the correct way to trigger the problem is to do the following:
- add CA cert to system nssdb, and set flags to trust it (e.g. TC,C,C)
- add the same CA cert to user nssdb with no trust in in (,, flags)
- remove CA cert from system nssdb

Remove operation does not seem to fully remove it from the sqlite db (as can be verified with sqlite3 cert9.db).

certutil -L output also indicates something is not as it should be.  Running as root:

# certutil -L -d sql:/etc/pki/nssdb/

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

and as user:

$ certutil -L -d sql:/etc/pki/nssdb/

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

cacert.org                                                   CT,C,C

$ certutil -L -d sql:$HOME/.pki/nssdb

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

cacert.org                                                   ,,

Comment 7 David Woodhouse 2010-09-23 14:36:32 UTC
(In reply to comment #6)
> Let's start by not mixing all issues together.  Reading this report, I believe
> the primary issue here is that when combining system and user nssdb data
> together, NSS may end up using trust flags from *deleted* system nssdb entry
> and certificate from *untrusted* user nssdb entry and trust in the combination
> of the two.

Yes.

> It may be better to keep concerns regarding which trust flags should trump the
> other aside for now.

It may. Or it may be that fixing that will also fix the primary issue. I do try to file separate bugs for separate issues where appropriate.

It may even be that this bug is *introduced* by the fix for another bug, such as bug 603313.

Comment 8 Elio Maldonado Batiz 2010-10-15 22:52:42 UTC
(In reply to comment #7) Dabid, I don't think the patch for bug 603313 is the cause, see the discussion in https://bugzilla.redhat.com/show_bug.cgi?id=643134, I'm testing a patch from Bob with good results. Could you try out the scratch build pointed at in https://bugzilla.redhat.com/show_bug.cgi?id=643134#c7 ?

Comment 9 Elio Maldonado Batiz 2010-10-31 23:43:19 UTC
Created attachment 456770 [details]
script to reproduce the bug / verify fix

Comment 10 Elio Maldonado Batiz 2010-11-01 17:11:58 UTC
Comment on attachment 456770 [details]
script to reproduce the bug / verify fix

Though I verfied the fix againts the Rawhide build at http://koji.fedoraproject.org/koji/buildinfo?buildID=202661
I also couldn't reproduce teh problem with prior builds. Did I oversimplify the bug reproduction steps?

Comment 11 David Woodhouse 2010-11-01 20:13:18 UTC
The original involved *deleting* the cert from the system database -- see comment 3

Comment 12 David Woodhouse 2010-11-01 20:17:34 UTC
Btw, it's probably best to use another machine that isn't on my ADSL line -- such as bombadil.infradead.org. And your tstclnt should surely be using sql:/etc/pki/nssdb (which with nsssysinit enabled will automatically also include the db from the user's home directory)

Comment 13 Elio Maldonado Batiz 2010-11-04 15:36:15 UTC
Created attachment 457828 [details]
script to reproduce the bug / verify fix

With the changes suggested in Comment 11 and Comment 12 this time I'm able to reproduce the bug.

Comment 14 Elio Maldonado Batiz 2010-11-04 16:26:35 UTC
Verification of the "fix" failed.

Comment 15 Tomas Hoger 2010-11-24 14:13:57 UTC
Elio, are we still in the "no fix available yet" state?

Comment 16 Elio Maldonado Batiz 2010-11-24 17:54:14 UTC
Yes, no fix yet. I am going to need Bob's help with this one.

Comment 17 Elio Maldonado Batiz 2010-11-24 18:05:05 UTC
Created attachment 462718 [details]
cert in DER used for testing

downloaded from http://www.cacert.org/certs/class3.der

Comment 18 Elio Maldonado Batiz 2011-01-22 19:28:56 UTC
Created attachment 474753 [details]
Fix to honor user's preferences regarding trust

Thank you Bob for the fix and the advise. Verified with attachment 457828 [details]. Also, 
listing via 'certutil -L -d sql:/etc/pki/nssdb' shows ,, in the trust column.

Comment 19 Fedora Update System 2011-01-22 20:19:07 UTC
nss-3.12.9-2.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/nss-3.12.9-2.fc14

Comment 20 Fedora Update System 2011-01-23 20:24:56 UTC
nss-3.12.9-2.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update nss'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/nss-3.12.9-2.fc14

Comment 21 Elio Maldonado Batiz 2011-01-23 22:40:03 UTC
Created attachment 474865 [details]
to reproduce / verify fix - with a few more steps

Comment 24 David Woodhouse 2011-01-26 09:04:43 UTC
I'm using the packages from updates-testing.

I have a passphrase set on my database in ~/.pki/nssdb.

I'm using a version of xulrunner with bug 546221 fixed. (I hope everyone who cares about the NSS system DB is doing so, too?)

Now *every* time I go to a form which needs passwords, I am asked for the passphrase for my NSS DB. Before updating to the new NSS packages, I was only ever asked *once* during the lifetime of each firefox process. I assume this wasn't an intentional change?

Comment 25 Elio Maldonado Batiz 2011-01-26 18:48:04 UTC
Created attachment 475463 [details]
Updated patch per upstream review requests

This is what is actually checked in upstream after we sent the fix for review.

Comment 26 Bob Relyea 2011-01-26 22:54:46 UTC
> Now *every* time I go to a form which needs passwords, I am asked for the
> passphrase for my NSS DB. Before updating to the new NSS packages, I was only
> ever asked *once* during the lifetime of each firefox process. I assume this
> wasn't an intentional change?

No, is this happening with the patches Elio sent out. It sounds like the root database is running as the default database. This would happen if you get the updated patches for NSS, but not the latest nsssysinit. (or the latest nsssysinit without the latest NSS).


bob

Comment 27 David Woodhouse 2011-01-27 00:05:02 UTC
Hm, sorry, do I have the wrong packages installed?

nss-3.12.9-2.fc14.i686
nss-3.12.9-2.fc14.x86_64
nss_compat_ossl-0.9.6-1.fc13.x86_64
nss_db-2.2.3-0.3.pre1.fc14.x86_64
nss-debuginfo-3.12.9-1.fc14.x86_64
nss-devel-3.12.9-2.fc14.x86_64
nss_ldap-265-6.fc14.x86_64
nss-mdns-0.10-8.fc12.i686
nss-mdns-0.10-8.fc12.x86_64
nss-softokn-3.12.9-1.fc14.i686
nss-softokn-3.12.9-1.fc14.x86_64
nss-softokn-devel-3.12.9-1.fc14.x86_64
nss-softokn-freebl-3.12.9-1.fc14.i686
nss-softokn-freebl-3.12.9-1.fc14.x86_64
nss-sysinit-3.12.9-2.fc14.x86_64
nss-tools-3.12.9-2.fc14.x86_64
nss-util-3.12.9-1.fc14.i686
nss-util-3.12.9-1.fc14.x86_64
nss-util-debuginfo-3.12.9-1.fc14.x86_64
nss-util-devel-3.12.9-1.fc14.x86_64
xulrunner-1.9.2.13-5.sysdb.fc14.x86_64

Comment 28 Elio Maldonado Batiz 2011-01-27 03:17:53 UTC
Created attachment 475517 [details]
V3: Updated patch per additional upstream review requests

Comment 29 Elio Maldonado Batiz 2011-01-27 03:28:46 UTC
(In reply to comment #27)
> Hm, sorry, do I have the wrong packages installed?
> 
Those were the right packages I posted on Sunday. Since then I pulled it the back from  updates testing because we though  prudent to get the patches reviewed and checked in upstream first. The changes made in response the review are not significant relative to what you have though. I'll make a scratch build available tomorrow so we can both check this.

Comment 30 David Woodhouse 2011-01-27 03:51:22 UTC
OK, thanks. The only thing I'm doing 'special' is fixing the bug that firefox doesn't use the shared nssdb, and setting a password on mine. It shouldn't be hard to reproduce.

Comment 31 Elio Maldonado Batiz 2011-01-27 23:48:06 UTC
(In reply to comment #30)
>It shouldn't be hard to reproduce. 
Well, if one has already the patched version of xulrunner :-)

The nss cratch build is here
http://koji.fedoraproject.org/koji/taskinfo?taskID=2746491

and a xulrunner scratch build with a like patch like yours applied
http://koji.fedoraproject.org/koji/taskinfo?taskID=2746491

I still have to test them. Unfortunately, I'm currently tied up with some time critical tasks and don't have time right now to pusue this.

Comment 32 Elio Maldonado Batiz 2011-01-28 20:11:40 UTC
I installed the updates and haven't had problems. I don't quite understand how to reproduce it as in:
> > Now *every* time I go to a form which needs passwords, I am asked for the
> > passphrase for my NSS DB. Before updating to the new NSS packages, I was only
> > ever asked *once* during the lifetime of each firefox process. I assume this
> > wasn't an intentional change?
> 
Could you offer us more details? For example, a site I could connect to (the ones I login and require password are either kerberos or ssh so nss is not involved) Is the remember password not working, did you went to another paged and came back to that of the site? 

> No, is this happening with the patches Elio sent out. It sounds like the root
> database is running as the default database. 
An the whole point of the patch is that the userdb be the default.

Comment 33 David Woodhouse 2011-01-29 00:04:15 UTC
(In reply to comment #32)
> Could you offer us more details?

I go to a site for which I have saved passwords. For example  https://clueless.aaisp.net.uk/main.cgi?GSEARCH

A pop-up appears, saying "Please enter the master password for the Software Security Device". I enter the password that I have on my sql:~/.pki/nssdb database and then it fills in the correct password for me.

I log *out* of the site in order to log in with another account (which is also remembered by firefox). But when I go back to the login URL, I get that 'Please enter the master password...' popup *again*.

I never used to get it more than once, in the lifetime of a firefox process.

Comment 34 Fedora Update System 2011-02-08 03:05:29 UTC
nss-3.12.9-5.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/nss-3.12.9-5.fc14

Comment 35 Fedora Update System 2011-02-08 23:00:42 UTC
nss-3.12.9-5.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update nss'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/nss-3.12.9-5.fc14

Comment 36 Elio Maldonado Batiz 2011-02-14 15:24:38 UTC
(In reply to comment #33)
I set up my own webserver that requires authentication, I can access it without any problems from my client machine whit the broswer configured to remember passwords, the user db with password, and a patched xulrunner. Password is remembers, as I navigate to others site and come back there is no additional prompt for it. The server is behind a firewall so I can't share it.

Comment 37 Fedora Update System 2011-02-27 21:34:29 UTC
Package nss-3.12.9-8.fc13,nss-softokn-3.12.9-5.fc13,nss-util-3.12.9-1.fc13,nspr-4.8.7-1.fc13:
* should fix your issue,
* was pushed to the Fedora 13 updates-testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing nss-3.12.9-8.fc13,nss-softokn-3.12.9-5.fc13,nss-util-3.12.9-1.fc13,nspr-4.8.7-1.fc13'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/nss-3.12.9-8.fc13,nss-softokn-3.12.9-5.fc13,nss-util-3.12.9-1.fc13,nspr-4.8.7-1.fc13
then log in and leave karma (feedback).

Comment 38 Fedora Update System 2011-03-01 04:22:39 UTC
nss-softokn-3.12.9-5.fc14, nss-3.12.9-8.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 39 Kai Engert (:kaie) (inactive account) 2011-03-03 18:13:49 UTC
*** Bug 636859 has been marked as a duplicate of this bug. ***

Comment 40 Fedora Update System 2011-03-07 20:55:24 UTC
nss-3.12.9-8.fc13, nss-softokn-3.12.9-5.fc13, nss-util-3.12.9-1.fc13, nspr-4.8.7-1.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.