Bug 204369 - Enrollment crashes ESC if cert has critical CRLDistributionPoint extension
Enrollment crashes ESC if cert has critical CRLDistributionPoint extension
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: esc (Show other bugs)
5.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jack Magne
Chandrasekar Kannan
RHEL5.0NACK
:
Depends On:
Blocks: 202042 203443
  Show dependency treegraph
 
Reported: 2006-08-28 15:00 EDT by Chandrasekar Kannan
Modified: 2015-01-04 18:20 EST (History)
2 users (show)

See Also:
Fixed In Version: RHBA-2007-0634
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-07 11:57:38 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Chandrasekar Kannan 2006-08-28 15:00:44 EDT
migration from http://raidzilla.sfbay.redhat.com/show_bug.cgi?id=57684




1/ perform enrollment with webstore token with client on rhel4 and the tps
server setup on solaris-9 64 bit.

enrollment completes. but ESC crashes. everytime we plug the token in after that
and when visiting the enrollment page, ESC crashes. 

attached are the ESC stack trace and TPS debug log.


------- Additional Comment #1 From Chandrasekar Kannan 2005-05-25 18:56 [reply]
-------

Created an attachment (id=24554) [edit]
esc stack trace and tps debug log


------- Additional Comment #2 From Chandrasekar Kannan 2005-05-25 18:56 [reply]
-------

I can't visit the format page either on rhel4. esc crashes. so can't format the
token on rhel4. trying windows


------- Additional Comment #3 From Thomas Kwan 2005-05-25 19:51 [reply] -------

I just checked that our CA has put CRLDistribution point extension into the
encryption, which upsets NSS.

Jack provided my the NSS stack trace.

From func PK11_ListCertsInSlot(slot);

Program received signal SIGSEGV, Segmentation fault.
0x00aeac35 in subject_list_sort (v1=0x9a037c0, v2=0x9a02ee8) at tdcache.c:157
157         if (dc1->isNewerThan(dc1, dc2)) {
Current language:  auto; currently c
(gdb) list
152     {
153         NSSCertificate *c1 = (NSSCertificate *)v1;
154         NSSCertificate *c2 = (NSSCertificate *)v2;
155         nssDecodedCert *dc1 = nssCertificate_GetDecoding(c1);
156         nssDecodedCert *dc2 = nssCertificate_GetDecoding(c2);
157         if (dc1->isNewerThan(dc1, dc2)) {
158             return -1;
159         } else {
160             return 1;
161         }
(gdb) print dc1
$1 = (nssDecodedCert *) 0x0
(gdb) pirnt dc2
Undefined command: "pirnt".  Try "help".
(gdb) print dc2
$2 = (nssDecodedCert *) 0x9a01858
(gdb) print dc1
$3 = (nssDecodedCert *) 0x0
(gdb) print v1
$4 = (void *) 0x9a037c0
(gdb) print v2
$5 = (void *) 0x9a02ee8
(gdb) print dc1
$6 = (nssDecodedCert *) 0x0
(gdb) print dc2
$7 = (nssDecodedCert *) 0x9a01858
(gdb) print c1
$8 = (NSSCertificate *) 0x9a037c0
(gdb) print c2
$9 = (NSSCertificate *) 0x9a02ee8
(gdb) print *c1;
Invalid character ';' in expression.
(gdb) print *c1
$10 = {object = {arena = 0x9a036c0, refCount = 1, lock = 0x9a03f90,
   instances = 0x9a037b0, numInstances = 1, trustDomain = 0x98b0050,
   cryptoContext = 0x0, tempName = 0x0}, type = NSSCertificateType_PKIX, id = {
   data = 0x9a03850, size = 1}, encoding = {data = 0x9a03860, size = 664},
 issuer = {data = 0x9a03b00, size = 62}, subject = {data = 0x9a03b58,
   size = 53}, serial = {data = 0x9a03b48, size = 4}, email = 0x0,
 decoding = 0x0}
(gdb) print *c2
$11 = {object = {arena = 0x9a26e80, refCount = 2, lock = 0x9a27010,
   instances = 0x9a02ed8, numInstances = 1, trustDomain = 0x98b0050,
   cryptoContext = 0x0, tempName = 0x0}, type = NSSCertificateType_PKIX, id = {
   data = 0x9a02f78, size = 1}, encoding = {data = 0x9a02f88, size = 596},
 issuer = {data = 0x9a031e8, size = 62}, subject = {data = 0x9a03240,
   size = 53}, serial = {data = 0x9a03230, size = 4}, email = 0x0,
 decoding = 0x9a01858}
(gdb)


When examined with manageobj, the util returns

...
 Compressed Object ID Size: 4
6b 35 00 00                                      k5..
 Object Attributes: 0x000050a2 Class = CKO_PUBLIC_KEY (2) id=2 flags
=TOKEN,ENCRYPT,WRAP,
 Attribute Count: 0
                                                                                
 Compressed Object ID Size: 4
6b 34 00 00                                      k4..
 Object Attributes: 0x0010a1b2 Class = CKO_PRIVATE_KEY (3) id=2 flags
=TOKEN,PRIVATE,DECRYPT,UNWRAP,SENSITIVE,
 Attribute Count: 0
FAILED Reading Object List (Schlumberger e-gate 0) status=AKAPDUFAIL,6,
winerr=SCARD_S_SUCCESS (0x0), appleterr = AKISO_UNAUTHORIZED 0x9c06


------- Additional Comment #4 From Thomas Kwan 2005-05-25 19:52 [reply] -------

Added Bob


------- Additional Comment #5 From Thomas Kwan 2005-05-25 19:54 [reply] -------

Also, Chandra marked the CRL distribution point extension as critical. NSS
should not crash. Wan-Teh suggested that we should try to include the extension,
but mark it as non-critical


------- Additional Comment #6 From Wan-Teh Chang 2005-05-25 22:49 [reply] -------

I found that CRL distribution points is an unsupported extension:
http://lxr.mozilla.org/security/source/security/nss/lib/util/secoid.c#782

This is enough to cause certificate decoding to fail:
http://lxr.mozilla.org/security/source/security/nss/lib/certdb/certdb.c#863
CERT_DecodeDERCertificate fails with SEC_ERROR_UNKNOWN_CRITICAL_EXTENSION because
http://lxr.mozilla.org/security/source/security/nss/lib/certdb/certxutl.c#504
cert_HasUnknownCriticalExten returns PR_TRUE because
http://lxr.mozilla.org/security/source/security/nss/lib/util/secoid.c#1776
SECOID_KnownCertExtenOID on CRL dist points returns PR_FALSE.

We can fix this crash at two levels.  At the higher level, we
can prevent undecodable certs from being passed to this
subject_list_sort function.  At the lower level, we can prevent
the subject_list_sort function from crashing on undecodable certs.

Here is a proposed fix at the lower level.  If we consider an
undecodable cert older than a decodable cert, we can implement the
subject_list_sort function like this:

static PRIntn subject_list_sort(void *v1, void *v2)
{
    NSSCertificate *c1 = (NSSCertificate *)v1;
    NSSCertificate *c2 = (NSSCertificate *)v2;
    nssDecodedCert *dc1 = nssCertificate_GetDecoding(c1);
    nssDecodedCert *dc2 = nssCertificate_GetDecoding(c2);
    if (!dc1) {
        return dc2 ? 1 : 0;
    } else if (!dc2) {
        return -1;
    } else {
        return dc1->isNewerThan(dc1, dc2) ? -1 : 1;
    }
}

I looked at the callers of subject_list_sort and tend to
think that we should fix this in subject_list_sort.


------- Additional Comment #7 From Wan-Teh Chang 2005-05-25 23:19 [reply] -------

I reviewed the other callers of nssCertificate_GetDecoding.

This should be fixed the same way.
http://lxr.mozilla.org/security/source/security/nss/lib/pki/pkistore.c#96

This is dead code.  It probably should be removed.
http://lxr.mozilla.org/security/ident?i=nssBestCertificate_Callback

This does not crash but should be reviewed for correctness.
http://lxr.mozilla.org/security/source/security/nss/lib/pki/certificate.c#443


------- Additional Comment #8 From Wan-Teh Chang 2005-05-25 23:53 [reply] -------

Bob,

I looked at the callers of subject_list_sort more.
This function is used when we add certs to the cache.
So the question is whether we want to add undecodable
certs to the cache.  If so, then my fix for subject_list_sort
is fine.  If not, then we need to fix this crash at a
higher level, probably in nssTrustDomain_AddCertsToCache.
nssTrustDomain_AddCertsToCache returns PRStatus but none
of its callers check the return value.  Also, all callers
of nssTrustDomain_AddCertsToCache call it to add only one
cert even though the function can add an array of certs
to the cache.

Note to self: pk11_fastCert has a memory leak.  It may
store an allocated string in *nickptr but return NULL.


------- Additional Comment #9 From Chandrasekar Kannan 2005-05-26 10:41 [reply]
-------

we plan to release note this for 7.1


------- Additional Comment #10 From John Magne 2005-05-26 10:42 [reply] -------

Sample debug stack trace of crash instance:


#0  0x008c8c35 in subject_list_sort (v1=0x854bb58, v2=0x854b2c0) at
tdcache.c:157
#1  0x008d88fc in nsslist_add_element (list=0x8549a28, data=0x854bb58)
    at list.c:225
#2  0x008d8abc in nssList_AddUnique (list=0x8549a28, data=0x854bb58)
    at list.c:272
#3  0x008c96a6 in add_subject_entry (arena=0x854c3f0, cache=0x840d958,
    cert=0x854bb58, nickname=0x856f370 "encryption key for testuser",
    subjectList=0xbfe4e894) at tdcache.c:578
#4  0x008c9c91 in add_cert_to_cache (td=0x840cf70, cert=0x854bb58)
    at tdcache.c:812
#5  0x008c9e77 in nssTrustDomain_AddCertsToCache (td=0x840cf70,
    certs=0xbfe4e8fc, numCerts=1) at tdcache.c:890
#6  0x008cce2a in cert_createObject (o=0x854bb20) at pkibase.c:1045
#7  0x008cca5a in nssPKIObjectCollection_GetObjects (collection=0x8549208,
    rvObjects=0x856efb8, rvSize=2) at pkibase.c:851
#8  0x008ccf74 in nssPKIObjectCollection_GetCertificates (collection=0x8549208,
    rvOpt=0x856efb8, maximumOpt=0, arenaOpt=0x0) at pkibase.c:1100
#9  0x0087dd21 in PK11_TraverseCertsInSlot (slot=0x8401c58,
    callback=0x87ec2c <listCertsCallback>, arg=0xbfe4e9dc) at pk11cert.c:2966
(More stack frames follow...)
(gdb) where
#0  0x008c8c35 in subject_list_sort (v1=0x854bb58, v2=0x854b2c0) at
tdcache.c:157
#1  0x008d88fc in nsslist_add_element (list=0x8549a28, data=0x854bb58)
    at list.c:225
#2  0x008d8abc in nssList_AddUnique (list=0x8549a28, data=0x854bb58)
    at list.c:272
#3  0x008c96a6 in add_subject_entry (arena=0x854c3f0, cache=0x840d958,
    cert=0x854bb58, nickname=0x856f370 "encryption key for testuser",
    subjectList=0xbfe4e894) at tdcache.c:578
#4  0x008c9c91 in add_cert_to_cache (td=0x840cf70, cert=0x854bb58)
    at tdcache.c:812
#5  0x008c9e77 in nssTrustDomain_AddCertsToCache (td=0x840cf70,
    certs=0xbfe4e8fc, numCerts=1) at tdcache.c:890
#6  0x008cce2a in cert_createObject (o=0x854bb20) at pkibase.c:1045
#7  0x008cca5a in nssPKIObjectCollection_GetObjects (collection=0x8549208,
    rvObjects=0x856efb8, rvSize=2) at pkibase.c:851
#8  0x008ccf74 in nssPKIObjectCollection_GetCertificates (collection=0x8549208,
    rvOpt=0x856efb8, maximumOpt=0, arenaOpt=0x0) at pkibase.c:1100
#9  0x0087dd21 in PK11_TraverseCertsInSlot (slot=0x8401c58,
    callback=0x87ec2c <listCertsCallback>, arg=0xbfe4e9dc) at pk11cert.c:2966
#10 0x0087ed9c in PK11_ListCertsInSlot (slot=0x8401c58) at pk11cert.c:3619
#11 0x00f08c88 in NSSManager::GetKeyPolicy (aKey=0xbfe4ea8c, aBuf=0xbfe4ea9c "",
    aBufLength=1024) at NSSManager.cpp:234
#12 0x00f12bc9 in NetKeyGetPolicy (aKey=0x0, aBuf=0x854d600 "",
    aBufLen=139768512) at netkey.cpp:785
#13 0x04933159 in rhNetKey::GetCOOLKeyPolicy (this=0x83fa960, aKeyType=0,
    aKeyID=0x856b2f0 "40900062ff02000065cb", policy=0x854b2c0)
    at rhNetKey.cpp:971


------- Additional Comment #11 From Thomas Kwan 2005-05-26 10:50 [reply] -------

For CS71 release note, 

ESC 1.1 does not support CRL Distribution Point Extension. Certificate profiles
for the token enrollment in the CA subsystem has CRL Distribution Point 
extension disable by default.


------- Additional Comment #12 From Chandrasekar Kannan 2006-08-18 22:30 [reply]
-------

per bug council on 08/18/2006, downgrade to P1. Jack to check if we can fix this.


------- Additional Comment #13 From Wan-Teh Chang 2006-08-18 23:28 [reply] -------

This is NSS bug
https://bugzilla.mozilla.org/show_bug.cgi?id=295754.
It has been fixed in NSS 3.10.2.  I'm sure ESC is
using NSS 3.11.x now.
Comment 1 Chandrasekar Kannan 2006-09-29 21:48:27 EDT
moving high/normal bugs to Target milestone 7.2(GA)
Comment 2 Chandrasekar Kannan 2006-10-19 13:57:17 EDT
per bug council on 10/19 - tfv=future

Jack, could you make sure that we have the version of nss mentioned here ?.
Comment 3 Chandrasekar Kannan 2007-03-20 07:20:15 EDT
per the last bug meeting, we decided this would be targeted in the rhel 5.1
release. 
Comment 4 Bob Lord 2007-03-28 13:27:43 EDT
This bug was proposed for RHEL 5, but wasn't resolved in time.
    devel_ack+ for RHEL 5.1.
Comment 5 Jack Magne 2007-06-06 15:01:54 EDT
For RHEL 5 this should be fixed because of the following:

1. ESC uses the system NSS.

2. The problem was fixed in NSS 3.10.2 .

3. ESC on RHEL5 uses the system NSS.

4. A RHEL5 box I checked is running NSS 3.11.5

Comment 8 Jack Magne 2007-08-17 12:52:17 EDT
Chandra: Did you not have a way to test this one previously?
Comment 9 Scott Haines 2007-08-17 17:13:02 EDT
This bug should be fixed.  Chandra to verify.
Comment 10 Chandrasekar Kannan 2007-08-17 19:17:38 EDT
I changed the Ca's encryption cert profile to add a critical
CRLDistributionPoint extension. ESC enrollment works. ESC view certificates
work. Smartcard login works.

here's the certificate.

Certificate  0x02ba
 
Certificate contents

    Certificate: 
        Data: 
            Version:  v3
            Serial Number: 0x2BA
            Signature Algorithm: SHA1withRSA - 1.2.840.113549.1.1.5
            Issuer: CN=Certificate Authority,O=Red Hat Security Domain,C=US
            Validity: 
                Not Before: Friday, August 17, 2007 4:13:37 PM PDT
America/Los_Angeles
                Not  After: Sunday, June 8, 2008 2:00:44 PM PDT America/Los_Angeles
            Subject: UID=ckannan,CN=Chandrasekar Kannan,OU=engineering,O=Red Hat
            Subject Public Key Info: 
                Algorithm: RSA - 1.2.840.113549.1.1.1
                Public Key: 
                    Exponent: 65537
                    Public Key Modulus: (1024 bits) :
                        C6:BB:60:A4:54:48:22:D1:90:9B:F9:54:A3:D9:BD:12:
                        81:E2:12:11:F1:F7:11:AC:28:9F:D6:05:D2:5B:13:A1:
                        B3:1C:C1:83:0F:98:D3:52:32:14:96:D9:9B:99:AD:4C:
                        3E:D1:09:2C:B8:9E:F9:C4:3A:9B:57:0C:73:43:06:23:
                        29:92:96:59:1C:F9:EB:33:9D:E2:3C:6F:4A:BB:11:AC:
                        DF:87:05:FB:FE:8D:6C:5C:94:16:FF:22:55:F3:92:05:
                        C1:B1:BA:8E:BB:BC:12:E7:B0:86:DE:9C:EE:1D:F4:6F:
                        AA:58:C9:83:EB:5F:C5:10:92:97:74:E6:E0:84:80:77
            Extensions: 
                Identifier: Key Usage: - 2.5.29.15
                    Critical: yes 
                    Key Usage: 
                        Key Encipherment 
                Identifier: Subject Alternative Name - 2.5.29.17
                    Critical: no 
                    Value: 
                        RFC822Name: ckannan@redhat.com
                Identifier: Subject Key Identifier - 2.5.29.14
                    Critical: no 
                    Key Identifier: 
                        4A:7C:85:AF:3A:95:5B:7E:53:57:2D:7F:8C:54:5A:24:
                        09:91:57:CF
                Identifier: Authority Key Identifier - 2.5.29.35
                    Critical: no 
                    Key Identifier: 
                        D0:48:59:58:8E:23:51:DF:80:79:E6:BA:0A:9C:99:2E:
                        0B:1A:59:63
                Identifier: Basic Constraints - 2.5.29.19
                    Critical: no 
                    Is CA: no 
                    Path Length Constraint: UNLIMITED
                Identifier: Authority Info Access: - 1.3.6.1.5.5.7.1.1
                    Critical: no 
                    Access Description: 
                        Method #0: ocsp
                        Location #0: URIName:
http://cseng.sfbay.redhat.com:9080/ca/ocsp
                Identifier: Extended Key Usage: - 2.5.29.37
                    Critical: no 
                    Extended Key Usage: 
                        1.3.6.1.5.5.7.3.2
                        1.3.6.1.5.5.7.3.4
                Identifier: CRL Distribution Points - 2.5.29.31
                    Critical: yes 
                    Number of Points: 1
                    Point 0
                        Distribution Point: [URIName:
http://cseng.sfbay.redhat.com:9080/ca/ee/ca/getCRL?crlIssuingPoint=MasterCRL&op=getCRL&crlDisplayType=cachedCRL&submit=Submit]
        Signature: 
            Algorithm: SHA1withRSA - 1.2.840.113549.1.1.5
            Signature: 
                67:20:91:EB:02:D4:49:1D:35:CF:80:6E:C8:2A:35:E2:
                94:EB:87:16:78:70:53:97:B5:7D:0B:7F:F7:48:02:5C:
                A0:F2:87:F8:58:CF:DF:C4:CE:D1:3D:45:0D:D6:0F:A5:
                8B:B1:F0:BF:D6:A2:C1:A4:E2:D8:8F:AF:40:AB:79:90:
                DE:92:98:9E:18:43:D7:97:FF:6A:E4:62:4B:6B:14:36:
                1D:58:16:9F:78:88:88:8B:6E:E5:F1:A4:FE:4E:FC:AF:
                7D:B8:7E:93:C1:55:03:D2:0F:28:4F:14:8A:69:2A:D5:
                EB:AA:4E:5E:CB:90:0F:C3:14:AC:C8:00:EE:F3:DA:AE:
                79:EF:C5:CE:6C:FA:B8:00:AF:C7:B6:26:34:58:2C:63:
                C1:A7:44:22:D6:3E:30:76:90:E0:37:BA:24:89:74:C6:
                BB:72:1C:E5:4C:82:3E:9C:80:53:A9:6A:70:05:46:62:
                55:74:7B:AD:C1:3B:CE:28:BD:42:01:D3:CA:DB:F4:72:
                EE:6A:85:85:79:89:BB:F0:A0:B2:8D:96:A2:71:1E:D9:
                BD:12:22:A4:3F:77:E9:1C:26:C9:32:44:FF:DF:61:33:
                AE:86:97:13:F5:38:B8:2D:25:A4:03:BD:C2:8E:C7:71:
                7D:81:7E:4D:24:37:19:7E:03:F9:F8:7D:83:EC:A8:A0
        FingerPrint
            MD2:
                B6:3E:97:6D:75:3B:3A:76:2D:D1:5F:A9:A1:48:DA:BD
            MD5:
                21:AE:89:01:30:10:18:83:98:3C:4B:6B:29:44:CC:B9
            SHA1:
                F6:09:28:82:C2:51:D5:89:01:4D:29:99:C6:F7:06:FC:
                7C:C5:8E:D0
            SHA256:
                A9:83:87:B5:D0:58:D6:52:16:EC:97:CB:7A:15:99:84:
                81:48:0E:54:B6:FA:D0:7B:CF:43:DD:36:A0:91:CA:23
            SHA512:
                39:DE:63:89:92:FE:CF:EC:50:72:4D:0E:3A:BD:8E:77:
                A8:F7:A2:FB:26:A8:A2:FA:96:63:D2:6C:23:78:6C:0E:
                96:4D:50:B2:1B:90:6A:CA:EE:DA:B2:E5:C8:F1:E1:FE:
                9B:17:66:7C:56:B1:08:91:86:4B:2C:B0:10:4E:85:C9


Comment 12 errata-xmlrpc 2007-11-07 11:57:38 EST
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 the 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-2007-0634.html

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