RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 643134 - nss trusts CAs it shouldn't
Summary: nss trusts CAs it shouldn't
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: nss
Version: 6.1
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Elio Maldonado Batiz
QA Contact: Aleš Mareček
URL:
Whiteboard:
Depends On: 633043
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-10-14 18:15 UTC by Elio Maldonado Batiz
Modified: 2012-04-29 12:06 UTC (History)
9 users (show)

Fixed In Version: nss-3.12.9-3.el6
Doc Type: Bug Fix
Doc Text:
Clone Of: 633043
Environment:
Last Closed: 2011-05-19 14:03:42 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
script to reproduce the bug / verify fix (874 bytes, application/x-sh)
2010-10-31 23:44 UTC, Elio Maldonado Batiz 		no flags Details
script to reproduce/verify fix corrected (1014 bytes, application/x-sh)
2010-11-05 19:23 UTC, Elio Maldonado Batiz 		no flags Details
get the ca certificate here (36 bytes, text/plain)
2010-11-05 19:28 UTC, Elio Maldonado Batiz 		no flags Details
Patch for bz64134 as applied in RHEL 6.1 (7.58 KB, patch)
2011-04-14 16:17 UTC, Elio Maldonado Batiz 		no flags Details | Diff
Bug 60301 reproducer of relevance to this bug (461 bytes, patch)
2011-04-14 19:19 UTC, Elio Maldonado Batiz 		no flags Details | Diff
Show Obsolete (1) View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:0692 0 normal SHIPPED_LIVE nspr, nss, nss-softokn, and nss-util bug fix and enhancement update 2011-05-19 09:37:17 UTC

Description Elio Maldonado Batiz 2010-10-14 18:15:28 UTC 
+++ This bug was initially created as a clone of Bug #633043 +++

[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...

--- Additional comment from dwmw2 on 2010-09-12 11:15:28 EDT ---

[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?

--- Additional comment from dwmw2 on 2010-09-12 11:16:04 EDT ---

[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

--- Additional comment from dwmw2 on 2010-09-12 11:22:44 EDT ---

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

--- Additional comment from dwmw2 on 2010-09-12 11:28:18 EDT ---

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 :)

--- Additional comment from dwmw2 on 2010-09-22 09:42:35 EDT ---

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?

--- Additional comment from thoger on 2010-09-23 09:19:57 EDT ---

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                                                   ,,

--- Additional comment from dwmw2 on 2010-09-23 10:36:32 EDT ---

(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 3 Bob Relyea 2010-10-15 16:59:16 UTC 
Deleted trust entries may not necessarily be deleted. If the certificate lives in a readonly database, it will *added* to a r/w database and marked untrusted. For the non-root user sql:/etc/pki/nssdb is read only.


It looks like both problems are really problems of trust order. My guess is /etc/pki/nssdb has the same or greater trust order than ~/.pki/nssdb, which is clearly wrong, at least for the normal default system out of the box.

This patch may fix the issue....

Index: nsssysinit.c
===================================================================
RCS file: /cvsroot/mozilla/security/nss/lib/sysinit/nsssysinit.c,v
retrieving revision 1.2
diff -u -r1.2 nsssysinit.c
--- nsssysinit.c	6 Feb 2010 04:56:37 -0000	1.2
+++ nsssysinit.c	15 Oct 2010 16:58:36 -0000
@@ -221,7 +221,7 @@
  * 2 for the key slot, and
  * 3 for the crypto operations slot fips
  */
-#define ORDER_FLAGS "trustOrder=75 cipherOrder=100"
+#define ORDER_FLAGS "cipherOrder=100"
 #define SLOT_FLAGS \
 	"[slotFlags=RSA,RC4,RC2,DES,DH,SHA1,MD5,MD2,SSL,TLS,AES,RANDOM" \
 	" askpw=any timeout=30 ]"
@@ -270,7 +270,7 @@
 	    "library= "
 	    "module=\"NSS User database\" "
 	    "parameters=\"configdir='sql:%s' %s tokenDescription='NSS user database'\" "
-        "NSS=\"%sflags=internal%s\"",
+        "NSS=\"trustOrder=75 %sflags=internal%s\"",
         userdb, stripped_parameters, nssflags,
         isFIPS ? ",FIPS" : "");
 
@@ -315,7 +315,7 @@
 	      "library= "
 	      "module=\"NSS system database\" "
 	      "parameters=\"configdir='sql:%s' tokenDescription='NSS system database' %s\" "
-	      "NSS=\"%sflags=internal,critical\"",sysdb, readonly, nssflags);
+	      "NSS=\"trustOrder=80 %sflags=internal,critical\"",sysdb, readonly, nssflags);
     }
 
     /* that was the last module */
Comment 4 Kamil Dudka 2010-10-15 19:17:10 UTC 
How are these flags supposed to interact with the corresponding flags from /etc/pki/nssdb/pkcs11.txt ?
Comment 5 Elio Maldonado Batiz 2010-10-15 19:44:11 UTC 
So far the patch isn't working for me, I can still connect as user even after setting the ca trust to ",," on the user's db. I have tried it as is where I had to disable David's nss-syinit-userdb-first pathc and also keeping both. I'll let Bob answer Kamil's question.
Comment 6 Elio Maldonado Batiz 2010-10-15 22:32:17 UTC 
(In reply to comment #4)
> How are these flags supposed to interact with the corresponding flags from
> /etc/pki/nssdb/pkcs11.txt ?
This flags will override what's in /etc/pki/nssdb/pkcs11.txt. After the patch the are the same as far as trust goes since the system config has tustOrder=75 already. The user one will get trustOrder=80.
Comment 7 Elio Maldonado Batiz 2010-10-15 22:41:36 UTC 
(In reply to comment #5) 
It takes a while to get the steps correctly but it's working for me now. 
I'm using Bob's patch and keeping David's patch as well. You can try the
scratch build at http://koji.fedoraproject.org/koji/taskinfo?taskID=2537298
I saved therm -f  srpm is at http://fedorapeople.org/~emaldonado/SRPMS/
Comment 8 Elio Maldonado Batiz 2010-10-31 23:44:26 UTC 
Created attachment 456771 [details]
script to reproduce the bug / verify fix
Comment 9 Elio Maldonado Batiz 2010-11-05 19:23:15 UTC 
Created attachment 458213 [details]
script to reproduce/verify fix corrected

I'm able to reproduce the bug with this script. Fix verification failed with a build where the suggested patch had been applied.
Comment 10 Elio Maldonado Batiz 2010-11-05 19:28:01 UTC 
Created attachment 458215 [details]
get the ca certificate here

PEM and DER formatted versions available, the script assumes you are using the DER one.
Comment 13 Aleš Mareček 2011-04-12 16:07:08 UTC 
Hi Elio,
I got "tstclnt: read from socket failed: Peer's Certificate has expired." as I told you on IRC. Did you try the reproducer again?
Comment 14 David Woodhouse 2011-04-12 16:27:50 UTC 
Please use bombadil.infradead.org not twosheds.infradead.org. That's actually a public-facing server, not on my ADSL line. I tend to be a little better at keeping its certificates up to date...
Comment 16 Elio Maldonado Batiz 2011-04-14 16:17:49 UTC 
Created attachment 492165 [details]
Patch for bz64134 as applied in RHEL 6.1
Comment 17 Elio Maldonado Batiz 2011-04-14 19:06:49 UTC 
Comment on attachment 492165 [details]
Patch for bz64134 as applied in RHEL 6.1

Somewhere else in the code trustOrder=100 is a default and notice the trustOrder changes
> 	    "module=\"NSS User database\" "
> 	    "parameters=\"configdir='sql:%s' %s tokenDescription='NSS user database'\" "
>-        "NSS=\"%sflags=internal%s\"",
>+        "NSS=\"trustOrder=75 %sflags=internal%s\"",


NSS User database gets trustOrder=75
> 
> 	      "module=\"NSS system database\" "
> 	      "parameters=\"configdir='sql:%s' tokenDescription='NSS system database' %s\" "
>-	      "NSS=\"%sflags=internal,critical\"",sysdb, readonly, nssflags);
>+	      "NSS=\"trustOrder=80 %sflags=internal,critical\"",sysdb, readonly, nssflags);
and NSS system database get trustOrder=80

The lower value is preferred over the higher one and thus the user db trust order flags are preferred over the inherited trust flags from the system db as they should.
Comment 18 Elio Maldonado Batiz 2011-04-14 19:19:48 UTC 
Created attachment 492209 [details]
Bug 60301 reproducer of relevance to this bug
Comment 19 Elio Maldonado Batiz 2011-04-14 19:23:26 UTC 
Comment on attachment 492209 [details]
Bug 60301 reproducer of relevance to this bug

Without attachment 492165 [details], what we applied for this one, bug 60301 fix verification fails.
Comment 20 Elio Maldonado Batiz 2011-04-14 19:30:13 UTC 
(In reply to comment #19) I meant to type bug 603101
Comment 22 Elio Maldonado Batiz 2011-04-14 19:47:21 UTC 
I retested the fixes bug 603011 with this patch removed.

The scratch build https://brewweb.devel.redhat.com/taskinfo?taskID=3257172
has the patches for this bug removed. I tested with it.

Without the patch:
[emaldona@rhel61tests ~]$ rpm -q nss
nss-3.12.9-8.1.el6.nopatch11.2.x86_64

[emaldona@rhel61tests ~]$ pk12util -d sql:/home/emaldona/.pki/nssdb -i ~/startcomcert.p12
Enter password for PKCS12 file: 
pk12util: PKCS12 IMPORT SUCCESSFUL
[emaldona@rhel61tests ~]$ pk12util -d sql:/etc/pki/nssdb -i ~/startcomcert.p12
Enter password for PKCS12 file: 
pk12util: PKCS12 decode import bags failed: Unable to import.  Error attempting to import private key.

After 'sudo yum distribution-synchronization'
With the patch:
[emaldona@rhel61tests ~]$ rpm -q nss
nss-3.12.9-8.el6.x86_64
[emaldona@rhel61tests ~]$ pk12util -d sql:/etc/pki/nssdb -i ~/startcomcert.p12
Enter password for PKCS12 file: 
pk12util: PKCS12 IMPORT SUCCESSFUL
Comment 24 errata-xmlrpc 2011-05-19 14:03:42 UTC 
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0692.html
Note You need to log in before you can comment on or make changes to this bug.