173715 - NSS crashes in OCSP

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P1)

Description

[Kai Engert [:KaiE:]]

NSS crashes when doing an OCSP certificate verification.

See bug 173711 for a test case and stack trace.

Comment 1

[Brant Gurganus]

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.

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

Marking P1.

In the stack trace in
http://bugzilla.mozilla.org/attachment.cgi?id=102442&action=view
it appears at first glance that ocsp_ConnectToHost called PR_Connect 
with a bogus net address and/or port number.  

PR_Connect asserts.  Maybe it shouldn't do that, but neither should
NSS be passing bogus netaddrs.

Comment 3

[Mark Warren]

When OCSP is enabled I do not see a crash, however, I do see the following error
when connecting to almost all https servers.

Error establishing an encrypted connection to foo.bar.com. Error Code: -5985.   

Examples of problematic servers include https://commcenter.attbi.com and
https://www.novusnet.com. The Yahoo! secure signon option and the EBay secure
signon do not trigger the above message.

Enable OCSP via Edit menu, Preferences..., Privacy & Security, Validation, "Use
OCSP to validate only certificates that specify an OCSP service URL". The -5895
error occurs with Mozilla 1.4beta, rc1, rc3 and 1.4 final. The newest version
I've used to reproduce this is (Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
rv:1.4) Gecko/20030624).  The error number corresponds to
PR_ADDRESS_NOT_SUPPORTED as defined in prerr.h (-5895L).  Setting the env vars
NSPR_LOG_MODULES=all:5 and NSPR_LOG_FILE=/tmp/moz.log provided some additional
logging info in moz.log.

Comment 4

[Mark Warren]

Whoops - a couple of typos above.  The correct error number is -5985 as in
(-5985L) in prerr.h.

Comment 5

[Mark Warren]

Error text is defined in SSLGenericError:
http://lxr.mozilla.org/seamonkey/source/security/manager/ssl/resources/locale/en-US/pipnss.properties#189

nsNSSIOLayer.cpp prints SSLGenericError w/ value PR_ADDRESS_NOT_SUPPORTED_ERROR
http://lxr.mozilla.org/seamonkey/source/security/manager/ssl/src/nsNSSIOLayer.cpp#833

and PR_ADDRESS_NOT_SUPPORTED_ERROR is used in these locations too:
http://lxr.mozilla.org/seamonkey/ident?i=PR_ADDRESS_NOT_SUPPORTED_ERROR

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

Mark, I'm not sure what comment 5 has to do with NSS.  
Are you proposing PSM changes in addition to NSS changes?
If so, please file a PSM bug. Thanks.

Comment 7

[Wan-Teh Chang]

Attachment: Proposed patch

The stack trace shows that 'hostIndex' was 0 and 'addr' was all
zeros, which was done by the memset(,0,) call in PR_EnumerateHostEnt.
I concluded this is what happened.

1. The OCSP responder was down, so PR_Connect to all of its
IP addresses failed.

2. Eventually PR_EnumerateHostEnt returned 0, indicating the
end of the IP address enumeration.  Here is the bug: we should
exit the do-while loop when PR_EnumerateHostEnt returns 0,
WITHOUT using 'addr'.  In other words, a return value of 0 means
we have stepped BEYOND the end of the IP address list; it doesn't
mean 'addr' is the last IP address on the list.  I have seen this
bug in some other code before, so I think the documentation of
PR_EnumerateHostEnt needs to be more clear about this point.

The fix is to exit the loop when PR_EnumerateHostEnt returns 0,
without doing the PR_Connect to 'addr'.

Comment 8

[Robert Relyea]

Comment on attachment 134041 [details] [diff] [review]
Proposed patch

This patch does what wan-teh describes.

Comment 9

[Wan-Teh Chang]

I've checked in this patch on the NSS trunk for NSS 3.9.

Julien, how do I test OCSP using Mozilla?  I will mark
this bug fixed after I have tested the modified code.

Comment 10

[Julien Pierre]

Wan-Teh,

1. Go to Edit/Preferences/Privacy & Security/Validation and select "Use OCSP to
validate only certificates that specify an OCSP service URL". Validate out of
preferences

2. go to Edit/Preferences/Privacy & Security/Certificates/Manage Certificates

3. double-click on some certs that you know have been revoked (eg. some of your
own if you renewed your cert recently with certificates.netscape.com)

4. it should say on top "could not verify this certificate because it has been
revoked"

Unfortunately, PSM disables OCSP before drawing the "Manage certificates" window
for performance reasons, so you can't immediately see which certs are revoked.
You have to click on each one. If you had a CRL, you would see <Revoked> under
purposes because CRL processing is never disabled.

Comment 11

[Nelson Bolyard (seldom reads bugmail)]

Wan-Teh,  was this bug fixed in NSS 3.9?  Your comment 9 suggests so.

Comment 12

[Wan-Teh Chang]

Marked the bug fixed.  The fix is in NSS 3.9.