Closed Bug 447882 Opened 16 years ago Closed 15 years ago

import NSS 3.12 RTM into hg to fix crasher that makes running Weave on a debug build impossible

Categories

(Core :: Security, defect)

Product:
Core
Component:
Security
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: dmosedale, Unassigned)

Details

Disabling the assertion in the NSS source makes it possible to run Weave in a Thunderbird debug build, but that seems suboptimal.

#0  0x9625bb9e in __kill ()
#1  0x9625bb91 in kill$UNIX2003 ()
#2  0x962d2ec2 in raise ()
#3  0x962e247f in abort ()
#4  0x00578d29 in PR_Assert (s=0x1b9c15fc "encode_kind == SEC_ASN1_INLINE && !optional", file=0x1b9c14d0 "secasn1d.c", ln=610) at /Users/dmose/s/comm-central-trunk/src/mozilla/nsprpub/pr/src/io/prlog.c:577
#5  0x1b9b796d in sec_asn1d_init_state_based_on_template (state=0xf32498) at secasn1d.c:610
#6  0x1b9b9d5a in sec_asn1d_next_in_sequence (state=0xf32438) at secasn1d.c:2023
#7  0x1b9bace2 in SEC_ASN1DecoderUpdate_Util (cx=0xf32410, buf=0xf33883 "0\n\006\b*H÷\r\002\aÚ`H\001e\003\004\001*ÚÚÚÚÚÚÚ\004\020£E£\vñ«|\nZâ\036", 'Ú' <repeats 153 times>..., len=12) at secasn1d.c:2672
#8  0x1b9bb2f6 in SEC_ASN1Decode_Util (poolp=0x19d17e40, dest=0xbfff75d0, theTemplate=0x1be0e4a0, buf=0xf33858 "05\004 \r0g̪¯)m\037÷ˤOU#N\"$í\n\023\033¬)0\002\002\020", len=55) at secasn1d.c:2962
#9  0x1b9bb355 in SEC_ASN1DecodeItem_Util (poolp=0x19d17e40, dest=0xbfff75d0, theTemplate=0x1be0e4a0, src=0xf33820) at secasn1d.c:2977
#10 0x1bca87e6 in pbe_PK11AlgidToParam (algid=0xf33814, mech=0x17540a50) at pk11pbe.c:799
#11 0x1bc9d1d2 in PK11_ParamFromAlgid (algid=0xf33814) at pk11mech.c:1239
#12 0x1bca9416 in PK11_PBEKeyGen (slot=0x9dd600, algid=0x19e59a90, pwitem=0xbfff87c0, faulty3DES=0, wincx=0x0) at pk11pbe.c:1368
#13 0x17eb88b8 in WeaveCrypto::DeriveKeyFromPassphrase ()
#14 0x17eb8a45 in WeaveCrypto::UnwrapSymmetricKey ()
#15 0x003d7d11 in NS_InvokeByIndex_P (that=0x18b05850, methodIndex=14, paramCount=6, params=0xbfffbab4) at /Users/dmose/s/comm-central-trunk/src/mozilla/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_unixish_x86.cpp:179
#16 0x114c63ab in XPCWrappedNative::CallMethod (ccx=@0xbfffbd0c, mode=XPCWrappedNative::CALL_METHOD) at /Users/dmose/s/comm-central-trunk/src/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp:2393
#17 0x114d0c31 in XPC_WN_CallMethod (cx=0x6682e0, obj=0x16d74cc0, argc=5, argv=0x19de4098, vp=0xbfffbe30) at /Users/dmose/s/comm-central-trunk/src/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp:1473
#18 0x00253f3f in js_Invoke (cx=0x6682e0, argc=5, vp=0x19de4090, flags=2) at jsinterp.cpp:1314
#19 0x00245d2b in js_Interpret (cx=0x6682e0) at /Users/dmose/s/comm-central-trunk/src/mozilla/js/src/jsinterp.cpp:4945
#20 0x00256fd0 in SendToGenerator (cx=0x6682e0, op=JSGENOP_SEND, obj=0x17050a00, gen=0x19de4000, arg=386204896) at /Users/dmose/s/comm-central-trunk/src/mozilla/js/src/jsiter.cpp:877
#21 0x00257523 in generator_op (cx=0x6682e0, op=JSGENOP_SEND, vp=0x18be7a7c) at /Users/dmose/s/comm-central-trunk/src/mozilla/js/src/jsiter.cpp:990
#22 0x00257568 in generator_send (cx=0x6682e0, argc=1, vp=0x18be7a7c) at /Users/dmose/s/comm-central-trunk/src/mozilla/js/src/jsiter.cpp:999
#23 0x00245cdd in js_Interpret (cx=0x6682e0) at /Users/dmose/s/comm-central-trunk/src/mozilla/js/src/jsinterp.cpp:4928
#24 0x00253fd0 in js_Invoke (cx=0x6682e0, argc=5, vp=0x19c0a558, flags=0) at jsinterp.cpp:1331
#25 0x0022af10 in fun_apply (cx=0x6682e0, argc=5, vp=0x19c0a540) at /Users/dmose/s/comm-central-trunk/src/mozilla/js/src/jsfun.cpp:1721
#26 0x00245cdd in js_Interpret (cx=0x6682e0) at /Users/dmose/s/comm-central-trunk/src/mozilla/js/src/jsinterp.cpp:4928
#27 0x00256fd0 in SendToGenerator (cx=0x6682e0, op=JSGENOP_SEND, obj=0x16d74880, gen=0x19e56590, arg=386501060) at /Users/dmose/s/comm-central-trunk/src/mozilla/js/src/jsiter.cpp:877
#28 0x00257523 in generator_op (cx=0x6682e0, op=JSGENOP_SEND, vp=0x19c0b518) at /Users/dmose/s/comm-central-trunk/src/mozilla/js/src/jsiter.cpp:990
#29 0x00257568 in generator_send (cx=0x6682e0, argc=1, vp=0x19c0b518) at /Users/dmose/s/comm-central-trunk/src/mozilla/js/src/jsiter.cpp:999
#30 0x00245cdd in js_Interpret (cx=0x6682e0) at /Users/dmose/s/comm-central-trunk/src/mozilla/js/src/jsinterp.cpp:4928
#31 0x00253fd0 in js_Invoke (cx=0x6682e0, argc=1, vp=0x18b314d4, flags=0) at jsinterp.cpp:1331
#32 0x114c0164 in nsXPCWrappedJSClass::CallMethod (this=0x13327680, wrapper=0x1caf0a00, methodIndex=3, info=0x905858, nativeParams=0xbfffe034) at /Users/dmose/s/comm-central-trunk/src/mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp:1523
#33 0x114b7f77 in nsXPCWrappedJS::CallMethod (this=0x1caf0a00, methodIndex=3, info=0x905858, params=0xbfffe034) at /Users/dmose/s/comm-central-trunk/src/mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp:565
#34 0x003d7ff4 in PrepareAndDispatch (self=0x1caf0a40, methodIndex=3, args=0xbfffe154) at /Users/dmose/s/comm-central-trunk/src/mozilla/xpcom/reflect/xptcall/src/md/unix/xptcstubs_unixish_x86.cpp:93
#35 0x003d8053 in nsXPTCStubBase::Stub3 (this=0x1caf0a40) at xptcstubsdef.inc:1
#36 0x003c3b3b in nsTimerImpl::Fire (this=0x1caefd30) at /Users/dmose/s/comm-central-trunk/src/mozilla/xpcom/threads/nsTimerImpl.cpp:403
#37 0x003c3d4e in nsTimerEvent::Run (this=0x1caf29b0) at /Users/dmose/s/comm-central-trunk/src/mozilla/xpcom/threads/nsTimerImpl.cpp:490
#38 0x003bd53a in nsThread::ProcessNextEvent (this=0x619d00, mayWait=0, result=0xbfffe2d4) at /Users/dmose/s/comm-central-trunk/src/mozilla/xpcom/threads/nsThread.cpp:510
#39 0x00348654 in NS_ProcessPendingEvents_P (thread=0x619d00, timeout=20) at nsThreadUtils.cpp:180
#40 0x11f1a04f in nsBaseAppShell::NativeEventCallback (this=0x64f040) at /Users/dmose/s/comm-central-trunk/src/mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp:121
#41 0x11ed57d4 in nsAppShell::ProcessGeckoEvents (aInfo=0x64f040) at /Users/dmose/s/comm-central-trunk/src/mozilla/widget/src/cocoa/nsAppShell.mm:302
#42 0x94e93615 in CFRunLoopRunSpecific ()
#43 0x94e93cf8 in CFRunLoopRunInMode ()
#44 0x9547cda4 in RunCurrentEventLoopInMode ()
#45 0x9547cbbd in ReceiveNextEventCommon ()
#46 0x9547ca31 in BlockUntilNextEventMatchingListInMode ()
#47 0x934f7505 in _DPSNextEvent ()
#48 0x934f6db8 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#49 0x934efdf3 in -[NSApplication run] ()
#50 0x11ed3b18 in nsAppShell::Run (this=0x64f040) at /Users/dmose/s/comm-central-trunk/src/mozilla/widget/src/cocoa/nsAppShell.mm:591
#51 0x12b54132 in nsAppStartup::Run (this=0x667570) at /Users/dmose/s/comm-central-trunk/src/mozilla/toolkit/components/startup/src/nsAppStartup.cpp:181
#52 0x000f8ded in XRE_main (argc=3, argv=0xbffff8fc, aAppData=0x60d940) at /Users/dmose/s/comm-central-trunk/src/mozilla/toolkit/xre/nsAppRunner.cpp:3180
#53 0x0000276b in main (argc=3, argv=0xbffff8fc) at /Users/dmose/s/comm-central-trunk/src/mail/app/nsMailApp.cpp:103
See also bug 400742
NSS's ASN.1 decoder ran into an ASN.1 template with an invalid combination
of flags.  This is not a bug in the decoder, (and the assertion should not
be removed).  Rather this is a bug in the ASN.1 template that was passed
to the decoder.  The question is: which of the many many templates in NSS
was the one?  The answer is not obvious from the stack trace.  

However, the fact that the trace includes a call to PK11_PBEKeyGen, which 
bears those magic 3 letters: PBE, make me suspect that the bad template 
was SEC_PKCS5V2PBEParameterTemplate, which was fixed (on the trunk) in a 
patch for bug 401928.  

Assuming you can reproduce this, you can tell by looking at this core file
in a debugger.  Get the address of SEC_PKCS5V2PBEParameterTemplate, and 
subtract it from (or compare it to) the address of "theTemplate" shown in 
the above stack.  If the difference is less than 100 bytes (for a 32-bit
build) or 200 bytes (for a 64-bit build), it's probably the same crash,
and the fix is to take a version of NSS with the fix for bug 401928.
Looks like we've got a winner:

(gdb) p &SEC_PKCS5V2PBEParameterTemplate
$3 = (SEC_ASN1Template (*)[6]) 0x1bf0e4a0
(gdb) p theTemplate
$4 = (const SEC_ASN1Template *) 0x1bf0e4a0
Component: Weave → Security
Product: Mozilla Labs → Core
QA Contact: weave → toolkit
Summary: NSS assertion in while generating keypair: Assertion failure: encode_kind == SEC_ASN1_INLINE && !optional, at secasn1d.c:610 → import NSS 3.12 RTM into hg to fix crasher that makes running Weave on a debug build impossible
Target Milestone: -- → ---
Version: unspecified → Trunk
What we've got in hg right now is 3.12 RC4, and reading through the tail end of bug 401928 suggests that the fixes we need were landed about a week after that tag was cut but before 3.12 RTM.
Flags: blocking1.9.1?
Well, it appears to me that bug 401928 was fixed after 3.12.0 RTM.
The fix is in 3.12.1, which is presently in Beta (not yet released). 
So, I guess the question is: when will 3.12.1 release as RTM, or 
at least a 3.12.1 release candidate tag, that could be taken into hg?
Do you (Weavers) agree that that is the question?
I am not sure what usually needs to happen for us to take a new NSS drop.  But whatever the usual procedure is, yes, we'll need 3.12.1 drop (or whatever release contains the fix we need).
I seed that, in the past, I have given two different answers to the question 
of which NSS release contains (or will contain) the fix.  I need to double 
check.  I'm taking that AI.
The template fix was rev 1.22 of mozilla/security/nss/lib/pk11wrap/pk11pbe.c
<http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/pk11wrap/pk11pbe.c&rev=1.22&mark=117-118#108>

According to 
<http://bonsai.mozilla.org/cvsgraph.cgi?file=mozilla/security/nss/lib/pk11wrap/pk11pbe.c> 
that revision has not yet been included in ANY tag of NSS 3.12.x, so I 
conclude that it is not in 3.12.0 RTM.  I was mistaken when I previously
indicated that it was fixed in 3.12.0 RTM

We are planning on making a 3.12.1, probably next week.
Flags: blocking1.9.1? → blocking1.9.1+
What's the status here? Either way, this doesn't seem like a release blocker to me, given that it doesn't directly impact average users.
Flags: blocking1.9.1+ → blocking1.9.1-
Well, if running weave on a debug build is now possible, or is no longer 
desirable, then I guess no fix is required.   (?!?!?!?)
I don't know if this is related, but valgrind reports a problem with the PBE code in pbe_PK11AlgidToParam.  Somewhere in the SEC_ASN1DecodeItem code the p5_param is accessed - the problem is that p5_param is uninitialized.  I think the solution would be something like this:

*** pk11pbe.c.~1.11.24.5.~	2006-06-15 18:01:35.000000000 -0600
--- pk11pbe.c	2009-03-30 13:48:06.000000000 -0600
***************
*** 416,422 ****
      SECStatus rv = SECFailure;
      int iv_len;
      
! 
      arena = PORT_NewArena(SEC_ASN1_DEFAULT_ARENA_SIZE);
      if (arena == NULL) {
  	goto loser;
--- 416,422 ----
      SECStatus rv = SECFailure;
      int iv_len;
      
!     memset(&p5_param, 0, sizeof(p5_param));
      arena = PORT_NewArena(SEC_ASN1_DEFAULT_ARENA_SIZE);
      if (arena == NULL) {
  	goto loser;
In reply to comment 11, 
Rich, the code you cited is in NSS 3.11.x, not in 3.12.x.
This file was largely rewritten for 3.12.x.
Is the problem still present in 3.12.x?
(In reply to comment #12)
> In reply to comment 11, 
> Rich, the code you cited is in NSS 3.11.x, not in 3.12.x.
> This file was largely rewritten for 3.12.x.
> Is the problem still present in 3.12.x?

Yes.  I did my testing with Fedora 10 i386 which uses NSS 3.12.2.0 (release 4).  I see it there, and in the current code I still see p5_param possibly having an uninitialized access:
http://mxr.mozilla.org/mozilla/source/security/nss/lib/pk11wrap/pk11pbe.c#770

And the code that was throwing the error is still here too:
http://mxr.mozilla.org/mozilla/source/security/nss/lib/util/secasn1d.c#1561
1560         /* Strip leading zeroes when target is unsigned integer */
1561         if (state->underlying_kind == SEC_ASN1_INTEGER && /* INTEGER   */
1562             item->len == 0 &&                             /* MSB       */
1563             item->type == siUnsignedInteger)              /* unsigned  */

In this case, item == state->dest == p5_param, so it's possible len and or type are being accessed uninitilized.
Rich, please file a separate bug about your issue. 
Include steps to reproduce and, if it's not too much, a stack for the place
where the problem occurs.  Thanks.
I filed  Bug 486060 about Rich's issue with pbe_PK11AlgidToParam.

I'd still like to see steps to reproduce there.
Sounds like Gecko 1.9.1 and mozilla-central already use versions of NSS with this bug fixed.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.