Bug 643134

Summary: nss trusts CAs it shouldn't
Product: Red Hat Enterprise Linux 6 Reporter: Elio Maldonado Batiz <emaldona>
Component: nssAssignee: Elio Maldonado Batiz <emaldona>
Status: CLOSED ERRATA QA Contact: Aleš Mareček <amarecek>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.1CC: amarecek, dwmw2, emaldona, kdudka, kengert, rob.townley, rrelyea, security-response-team, thoger
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: nss-3.12.9-3.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 633043 Environment:
Last Closed: 2011-05-19 14:03:42 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 633043    
Bug Blocks:    
Attachments:
Description Flags
script to reproduce the bug / verify fix
none
script to reproduce/verify fix corrected
none
get the ca certificate here
none
Patch for bz64134 as applied in RHEL 6.1
none
Bug 60301 reproducer of relevance to this bug none

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