bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

crypto.generateCRMFRequest used to generate DSA request: crash

RESOLVED FIXED in mozilla2.0b8



Security: PSM
17 years ago
7 years ago


(Reporter: awnuk, Assigned: kaie)


({crash, testcase})

Windows NT
crash, testcase

Firefox Tracking Flags

(status1.9.2 .13-fixed, status1.9.1 .16-fixed)


(Whiteboard: [sg:dos][kerh-brz][psm-fatal][psm-enroll], URL)


(2 attachments)



17 years ago
I'm using  2001-10-01-05-0.9.4. 
crypto.generateCRMFRequest used according to 
to generate DSA request is crashing 6.2.


17 years ago
Priority: -- → P1

Comment 1

17 years ago
Worksforme. There are some DSA tests at http://junruh.mcom.com/tests.html on the
right side under "CMS 4.2 Testing."
Ever confirmed: true

Comment 2

17 years ago
This only happens when you pass PQG via "keyParamsN".
Severity: critical → normal
Priority: P1 → P2

Comment 3

17 years ago
cc lakshmi.
crash keyword.
Assignee: ssaux → javi
Keywords: crash
Priority: P2 → P1
Target Milestone: --- → Future

Comment 4

17 years ago
awnuk, can you zip up the html file and email it to me so that I can add it to
my CMS server for testing?

Comment 6

16 years ago
Is this still happening? How can I reproduce the crash?

Comment 7

15 years ago
By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and
<http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss
bugs are of critical or possibly higher severity.  Only changing open bugs to
minimize unnecessary spam.  Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.
Severity: normal → critical
Mass reassign Javi's old PSM bugs to nobody
Assignee: javi → nobody
QA Contact: junruh → nobody
Target Milestone: Future → ---


13 years ago
Component: Security: UI → Security: UI
Product: PSM → Core
Here's a 4 year old P1 critical bug.  :(

The URL cited above is now long gone.  It was

The only docs I could find related to crypto.generateCRMFRequest
on docs.sun.com were

One of the arguments to crypto.generateCRMFRequest is a string intended
to be used to pass the PQG parameters needed when generating a DSA cert.
If the string is absent (null), crypto.generateCRMFRequest makes up a 
new PQGparams on the spot, which may be ok for playing, but isn't very
useful with a real DSA-based CA.  

Sadly, it appears that crypto.generateCRMFRequest ONLY works for DSA if
the string is null.  If the string is non-null, there is no code to handle
that case.  See function nsConvertToActualKeyGenParams near 

I suspect that is the root cause of this ~4 year old bug
Here is some additional documentation on crypto.generateCRMFRequest, based 
partly on a posting by Steve Parkinson

      crmfObject = crypto.generateCRMFRequest(
             subject.value,          // 'CN=Fred'
             "regToken",             // string defined by CRMF, may be null
             "authenticator",        // string defined by CRMF, may be null
// if present, the above two strings are placed into the CRMF request as
// UTF8 encoded strings.
             null,                   // string containing RA's cert for key
                                     // escrow (base 64 encoded), or null
// note, if the cert string is not NULL, the user will be shown a dialog 
// informing him that key escrow will be done.  
             "setCRMFRequest();",    // required callback invocation
// the next 3 arguments are taken as a triplet.  
// there may be as many triplets as there are desired key pairs to be 
// generated. The 3 argument values in each triplet are: 
//  - key size in bits, 
//  - base 64 encoded string containing PQG or DH params, or null 
//    for RSA use null
//  - a string identifying the type of key pair to gen.  See below
             1024, null, keyGenAlg); // key parameters

    keyGenAlg can be 
       "rsa-sign"     (signature key) or 
       "rsa-ex"       (encryption) or 
       "rsa-dual-use" (both)

Other defined values include


    the cert request (in CRMF format) is retrieved by accessing:

I suspect that much of this is untested.  NSS contains a test page (html)
and test cgi script for it, but it tests only a tiny subset of the 
combinations of key types and sizes provided.

Comment 11

13 years ago
Created attachment 192124 [details]
Javascript API doc from PSM 1.1

I found an old PSM distribution with the missing doc. Hope it's useful.
That's a great doc, Wan-Teh.   Thanks.

The CRMF code in PSM and NSS is an orphan.  It is demonstrably broken and
incorrect in several ways.  (See the NSS CRMF bugs, some of which are assigned 
to me since I worked at AOL.)  It needs someone who wants it to own it. 
Might that be RedHat's CMS team?


13 years ago
Whiteboard: [kerh-brz]
QA Contact: nobody → ui


10 years ago
Version: psm2.0 → 1.0 Branch


10 years ago
Version: 1.0 Branch → Trunk
Assignee: nobody → kaie
Component: Security: UI → Security: PSM
QA Contact: ui → psm


8 years ago
Group: core-security


8 years ago
Depends on: 572809

Comment 13

8 years ago
I'm able to reproduce the crash.

PSM function nsConvertToActualKeyGenParams says:

    // For DSA, we don't support passing in key generation arguments from
    // the JS code just yet.

It contains a check that tries to simply abort when giving parameters

    if (params)
      return nsnull;

but apparently this doesn't work. The code will continue, it will call into PK11_GenerateKeyPair using NULL parameters, which will forward the call elsewhere, and finally crash, when the code attempts to dereference a null pointer.

#0  0x01b52200 in PK11_GenerateKeyPairWithOpFlags (slot=0xa7819c00, type=16, param=0x0, pubKey=0xa473ed50, attrFlags=69, opFlags=0, opFlagsMask=0, wincx=0xa499e140) at pk11akey.c:1263
#1  0x01b52bab in PK11_GenerateKeyPairWithFlags (slot=0xa7819c00, type=16, param=0x0, pubKey=0xa473ed50, attrFlags=69, wincx=0xa499e140) at pk11akey.c:1507
#2  0x01b52c1b in PK11_GenerateKeyPair (slot=0xa7819c00, type=16, param=0x0, pubKey=0xa473ed50, token=1, sensitive=1, wincx=0xa499e140) at pk11akey.c:1531

1260        case CKM_DSA_KEY_PAIR_GEN:
1261            dsaParams = (SECKEYPQGParams *)param;
1262            attrs = dsaPubTemplate;
1263            PK11_SETATTRS(attrs, CKA_PRIME, dsaParams->prime.data,
1264                                    dsaParams->prime.len); attrs++;

If you would like to reproduce the crash, go to:
Summary: crypto.generateCRMFRequest used to generate DSA request is crashing 6.2 → crypto.generateCRMFRequest used to generate DSA request: crash


8 years ago
Whiteboard: [kerh-brz] → [kerh-brz][psm-fatal]

Comment 14

8 years ago
The crash is not limited to "dsa-sign", but can be reproduced with "rsa-dual-use", and probably other combinations, too.

The following links looks similar, but is different. dsa vs. rsa.


Comment 15

8 years ago
Created attachment 452038 [details] [diff] [review]
Patch v1

The patch in bug 572809 is one way to fix this bug.

However, given that Mozilla application users might continue to use older NSS versions for a while, I propose to use a patch at the PSM level, too.

Unfortunately, the patch at the PSM level has the slight risk that we might introduce a regression in the interaction with consumers of the related JavaScript function. I've contacted the maintainers of Red Hat Certificate System, which are an important consumer, and have asked them to help testing.
Attachment #452038 - Flags: review?(rrelyea)

Comment 16

8 years ago
Is it true that former Sun = Oracle has a Certificate System that might be a consumer of this function, too?

Should we involve them for testing and QA resources?
Crashes that are always a null deref (with no way to generate an arbitrary offset from null) generally do not need to be security-sensitive. They are not exploitable beyond the denial of service.  [DoS bugs in NSS server code might be another matter; the NSS team should make that call.]
Keywords: testcase
Whiteboard: [kerh-brz][psm-fatal] → [sg:dos][kerh-brz][psm-fatal]


8 years ago
Whiteboard: [sg:dos][kerh-brz][psm-fatal] → [sg:dos][kerh-brz][psm-fatal][psm-enroll]

Comment 18

8 years ago
Comment on attachment 452038 [details] [diff] [review]
Patch v1

r+ I don't know why it took so long for me to get to this simple patch.

Attachment #452038 - Flags: review?(rrelyea) → review+

Comment 19

8 years ago
Comment on attachment 452038 [details] [diff] [review]
Patch v1

Requesting approval for this trivial null-check crasher fix.
Attachment #452038 - Flags: approval2.0?


8 years ago
Attachment #452038 - Flags: approval1.9.2.13?
Comment on attachment 452038 [details] [diff] [review]
Patch v1

Do we need or want this on 1.9.1 branch as well? Approved for, a=dveditz for release-drivers
Attachment #452038 - Flags: approval1.9.2.13? → approval1.9.2.13+

Comment 21

8 years ago
Comment on attachment 452038 [details] [diff] [review]
Patch v1

ok, should land on 1.9.1.x too

I'll wait with any landing until I have trunk approval.
Attachment #452038 - Flags: approval1.9.1.16?
Comment on attachment 452038 [details] [diff] [review]
Patch v1

Approved for, a=dveditz for release-drivers
Attachment #452038 - Flags: approval1.9.1.16? → approval1.9.1.16+
Attachment #452038 - Flags: approval2.0? → approval2.0+
Last Resolved: 7 years ago
status1.9.1: --- → .16-fixed
status1.9.2: --- → .13-fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b8
Group: core-security
You need to log in before you can comment on or make changes to this bug.