156042 - Crash when certificate not issued by a valid authority

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P2)

Description

[Olivier Cahagne]

Mozilla: build 2002070604 (trunk) on Win2k.

I can reproduce a crash on our Intranet (which didn't crash previous builds, or
certificate might have changed in the time being...), by loading page and it'll
crash immediately.
I know this is not a great bug report because missing any public Web site to
test with but I hope the Talkback data can help: TB8054145G.

I believe this error comes from the certificate because Mozilla is fairly
stable, used to work on this site and IE pops up a warning about the
certificate, mentioning it was not issued by a trusted certificate authority.

Comment 1

[Olivier Cahagne]

Removing keyword 'regression' as Mozilla 1.0 crashes too, Mozilla 1.1a crashes too.

Comment 2

[Olivier Cahagne]

Also crashing with a fresh profile, server is running Netscape Enterprise 3.6
SP3 (I'm not using HTTP Pipelining). I can e-mail the stack trace privately (as
part of the Intranet, stack trace contains some CA information, not critical
though).

Comment 3

[[e-mail] (gone - use [e-mail] instead)]

nss3.dll + 0x2380e (0x6109380e) 

eek, that's it.  if this is reproducible, maybe a later crash will provide a
better stack?

Comment 4

[Olivier Cahagne]

crashing on Linux build 2002070508 (trunk): TB8061455Q, TB8061441Q. On Win2k:
TB8061315G, TB8054722X.
If I disable SSLv3 (untick SSLv3 in Privacy & Security -> SSL), it won't crash,
Mozilla will simply warn about untrust certificate and go on (I believe it falls
back on SSLv2).
However, when I edit ciphers manually (and re-enable SSLv3 to force Mozilla
using one of these ciphers), any SSLv3/TLS cipher crashes if it's recognized by
the server.
Cert was issued on June, 19th, hence the reason why I didn't crash before. It's
using RC4 128 bit, SHA-1 (also has a MD5 fingerprint).
A sniffer shows traffic with a single SSL Hello, then Mozilla crashes.

Comment 5

[Olivier Cahagne]

Looking at the sniffer trace, could it be that the certificate contains some
characters not properly handled by Mozilla ?
ex.: "file://\\companyrootca\CertEnroll\companyrooca_Company Root CA.crt"

Comment 6

[Boris Zbarsky [:bzbarsky]]

Windows stacks from comment 4 are what Stephen saw in comment 3.  Linux ones are:

CERT_CopyName()
CERT_CopyGeneralName()
CERT_CopyNameConstraint()
CERT_GetNameConstriantByType()
CERT_CompareNameSpace()
CERT_VerifyCertChain()
CERT_VerifyCert()
CERT_VerifyCertNow()
SSL_AuthCertificate()
AuthCertificateCallback()
ssl3_HandleCertificate()
ssl3_HandleHandshakeMessage()
ssl3_HandleHandshake()
ssl3_HandleRecord()
ssl3_GatherCompleteHandshake()
ssl_GatherRecord1stHandshake()
ssl_Do1stHandshake()
ssl_SecureSend()
ssl_SecureWrite()
ssl_Write()
nsSSLIOLayerWrite()
PR_Write()
nsSocketOS::Write()
nsSocketOS::WriteFromSegments()
ConstCharImpl::ReadSegments()
nsSocketOS::WriteFrom()
nsHttpTransaction::OnDataWritable()
nsHttpConnection::OnDataWritable()
nsSocketWriteRequest::OnWrite()
nsSocketTransport::doReadWrite()
nsSocketTransport::Process()
nsSocketTransportService::Run()
nsThread::Main()
_pt_root()
libpthread.so.0 + 0x60ee (0x402020ee) 

Comment 7

[Stephane Saux]

cc relyea
->Kai

Comment 8

[Stephane Saux]

Reporter. Can you try a new profile?

Comment 9

[Olivier Cahagne]

see comment 2, I've tried that and I still crash.

Comment 10

[Kai Engert (:KaiE:)]

Without being able to reproduce ourselves, I don't see much hope to understand
what's going wrong.

Would it help the NSS team to analyze the problem, if you had access to the
public cert?

The only information we have now is, it crashes directly within CERT_CopyName.
That is, it must be crashing trying to dereference an invalid pointer in that
function.

SECStatus
CERT_CopyName(PRArenaPool *arena, CERTName *to, CERTName *from)
{
    CERTRDN **rdns, *frdn, *trdn;
    SECStatus rv;

    CERT_DestroyName(to);
    to->arena = arena;

    /* Copy each rdn from from */
    rdns = from->rdns;
    while ((frdn = *rdns++) != 0) {
	trdn = CERT_CreateRDN(arena, 0);
	if ( trdn == NULL ) {
	    return(SECFailure);
	}
	rv = CERT_CopyRDN(arena, trdn, frdn);
	if (rv) return rv;
	rv = CERT_AddRDN(to, trdn);
	if (rv) return rv;
    }
    return SECSuccess;
}

I see the following possible crashes:
- to is NULL
- from is NULL
- from->rdns is null

I don't think I can do much, this is a crash within NSS.

Comment 11

[Olivier Cahagne]

With proper asserts, perhaps I can check if indeed one of these are null ?
However, I won't be able to access my Linux box for the next 10 days, I'll only
be able to check this on Win2k where I cannot build Mozilla myself.

Comment 12

[Kai Engert (:KaiE:)]

cc'ing more people. I think the problem is caused by NSS.

Comment 13

[Olivier Cahagne]

I just ran a debug Linux build, here's the stack trace (build 2002072908 trunk
built from source).

0x4237ff05 in CERT_CopyName (arena=0x8826ba8, to=0x88321e4, from=0x882ef6c)
    at secname.c:465
465	    while ((frdn = *rdns++) != 0) {

I'll try to add some asserts (I'm not a programmer though :).Hope this helps anyway.

Comment 14

[Julien Pierre]

Olivier,

Could you provide us with the cert.db file from your Netscape enterprise server
3.6 ? This file will contain the public certificate of your server without the
private key. This would allow us to parse the certificate and see what's going on.

I note that CERT_CopyName doesn't have much in the way of error checking. A
patch could be made to it. Eg, check for valid arguments passed in, check rdns
before dereferencing it, etc.

Comment 15

[Kai Engert (:KaiE:)]

Over to NSS. Null pointer dereference.

Comment 16

[Wan-Teh Chang]

Assigned the bug to Julien.

Comment 17

[Julien Pierre]

Attachment: add error checking

Comment 18

[Julien Pierre]

Without seeing the exact line of the crash, I don't exactly know the cause of
the error. However, I have created a patch to add some error checking in
CERT_CopyName. This might resolve the problem. You will need to rebuild NSS from
the tip to try it.

Checking in secname.c;
/cvsroot/mozilla/security/nss/lib/certdb/secname.c,v  <--  secname.
new revision: 1.9; previous revision: 1.8
done

Comment 19

[Olivier Cahagne]

will try this on Linux tonight and confirm if it fixes the crash.
Unfortunately, I couldn't get the cert.db file (webmaster didn't answer me).

Comment 20

[Olivier Cahagne]

applied the fix on 20020920 source on Linux, built Mozilla from scratch 'gmake
-f client.mk build' still crashes with same stack trace.
Is there a way I can debug, add asserts, etc. ?

Comment 21

[Julien Pierre]

You need to build NSS separately from the browser, as the NSS version I made the
changes on is not integrated with the browser source yet. When you do gmake -f
client.mk, it pulls an old version of NSS. We are in the process moving Mozilla
to NSS 3.6 beta 1, but that still won't have the fix I made yesterday.

Since you already built the client, what you could do is :
rm -rf mozilla/security/nss
cvs co mozilla/security/nss
cd mozilla/security/nss
setenv NSPR_AUTOCONF 1
gmake nss_build_all

This should give you a new set of .sos under mozilla/dist/$OBJDIR/lib
Copy them over the ones in your browser and see if it still crashes.

Comment 22

[Olivier Cahagne]

Attachment: OpenSSL client mode connecting to mco.cisco.com

Comment 23

[Olivier Cahagne]

doesn't crash anymore using build 2003012308 on Linux.

Comment 24

[Wan-Teh Chang]

Patch checked in on the NSS_3_4_BRANCH (3.4.4) because
one of the patches for bug 204555 depends on this patch.