614342 - PSM crashes with certain certificates. Potentially exploitable , for example, Firefox will crash when visiting a remote https site.

Status: VERIFIED DUPLICATE of bug 529485

(Core :: Security: PSM, defect)

Description

[Andrey Jivsov]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.12) Gecko/20101027 Fedora/3.6.12-1.fc13 Firefox/3.6.12
Build Identifier:  Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.12) Gecko/20101027 Fedora/3.6.12-1.fc13 Firefox/3.6.12

Because the crash appears to be is in the parsing code of X.509 certificate, the problem is remotely exploitable with a rogue HTTPs service. It is also present when user imports PKCS#12 files into Firefox or Thunederbird. Crashing is 100% reproducible.

Reproducible: Always

Steps to Reproduce:
The following steps are for remote DoS attach on Firefox. I will use openssl to establish a sample HTTPs site, accessible as https://localhost:1111.

1. Set up the HTTPs service. [Certificate content is omitted due to sensitive nature and will be provided in private e-mail or after confirmation that it is OK to post.]

a) Create file openssl-key.pem with the following content:
	-----BEGIN PRIVATE KEY-----
...
	-----END PRIVATE KEY-----

b) Create file openssl-cert.pem with the following content:
	-----BEGIN CERTIFICATE-----
...
	-----END CERTIFICATE-----

c) Now run:
	openssl s_server -key openssl-key.pem -cert openssl-cert.pem -accept 1111
This creates a TLS service on localhost:1111.

2. Type https://localhost:1111 in the Firefox.

3. The certificate warning page "This connection is untrusted" comes up. 
a) User is forced to select "I understand the risks", click "Add Exception...".
b) If use clicks "View" button in the "Add Security Exception" dialog, Firefox crashes. This is a logical step to take before clicking "Confirm Security Exception".

-----

The simpler steps to reproduce are 
1. import a sample PKCS#12 file
2. view the imported certificate; Firefox or Thunderbird will crash.

Observed on Windows Thunderbird (latest released), Linux Thunderbird (3.1.6) and Firefox (3.6.12).

Actual Results:  
Firefox or Thunderbird crash any time certificate view dialog is invoked.

Expected Results:  
Certificate content is displayed. 

Please contact [e-mail] for details. Or, please confirm that it is OK to post remaining details into this bug. I clicked the "Many users will be harmed by this security problem" checkbox.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

Post all your details in this bug.  
A stack trace is the single most desirable detail.

Comment 2

[Andrey Jivsov]

Attachment: openssl-cert.pem

The certificate that is crashing NSS. I believe the problem is with AuthorityKeyIdentifier extension.

Comment 3

[Andrey Jivsov]

Attachment: openssl-key.pem

The corresponding private key

Comment 4

[Andrey Jivsov]

Attachment: PKCS#12 file with an X.509 cert that will crash NSS. Password is 12345678

First, import this keypair into Firefox or Thunderbird. Next, clicking on the certificate to examine it will crash these products.

Comment 5

[Andrey Jivsov]

Attachment: Crash dump: ProcessAuthKeyId crashes @ nsNSSCertHelper.cpp:1277

The relevant sample from the attached Thunderbird crash:

[...]
Thread 1 (Thread 7270):
[...]
#3  ProcessAuthKeyId (extension=0x7f80785061d0, ev_oid_tag=SEC_OID_UNKNOWN, 
    nssComponent=0x7f808e147010, retExtension=0x7fff9cd700f0)
    at /usr/src/debug/thunderbird-3.1.6/comm-1.9.2/mozilla/security/manager/ssl/src/nsNSSCertHelper.cpp:1277
        ret = <value optimized out>
        arena = 0x7f8076ef5240
        rv = 0
        local = {<nsFixedString> = {<nsString> = {<nsAString_internal> = {
                mData = 0x7fff9cd6fc40, mLength = 0, mFlags = 
    65553}, <No data fields>}, mFixedCapacity = 63, mFixedBuf = 
    0x7fff9cd6fc40}, mStorage = {0, 101, 121, 32, 73, 68, 0, 0, 25923, 29810, 
    30020, 28781, 30789, 25972, 29550, 28521, 29550, 39936, 32767, 0, 63488, 
    30441, 32640, 0, 63488, 30441, 32640, 0, 58, 0, 9, 0, 28688, 36372, 
    32640, 0, 0, 0, 0, 0, 0, 0, 0, 0, 26369, 64, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
    0, 65008, 40150, 32767, 0, 62016, 36373, 32640, 0}}
#4  ProcessExtensionData (extension=0x7f80785061d0, ev_oid_tag=
    SEC_OID_UNKNOWN, nssComponent=0x7f808e147010, retExtension=0x7fff9cd700f0)
    at /usr/src/debug/thunderbird-3.1.6/comm-1.9.2/mozilla/security/manager/ssl/src/nsNSSCertHelper.cpp:1668
        rv = <value optimized out>
#5  ProcessSingleExtension (extension=0x7f80785061d0, ev_oid_tag=
    SEC_OID_UNKNOWN, nssComponent=0x7f808e147010, retExtension=0x7fff9cd700f0)
    at /usr/src/debug/thunderbird-3.1.6/comm-1.9.2/mozilla/security/manager/ssl/src/nsNSSCertHelper.cpp:1732
        extvalue = {<nsFixedString> = {<nsString> = {<nsAString_internal> = {
                mData = 0x7fff9cd6fce0, mLength = 0, mFlags = 
    65553}, <No data fields>}, mFixedCapacity = 63, mFixedBuf = 
    0x7fff9cd6fce0}, mStorage = {0, 105, 122, 101, 58, 32, 56, 32, 66, 121, 
    116, 101, 115, 32, 47, 32, 54, 52, 32, 66, 105, 116, 115, 10, 102, 102, 
    32, 56, 57, 32, 55, 54, 32, 102, 100, 32, 55, 54, 32, 49, 100, 32, 99, 
    53, 32, 102, 101, 32, 0, 105, 112, 104, 101, 114, 109, 101, 110, 116, 10, 
    0, 48, 32, 0, 1}}
        oidTag = SEC_OID_X509_AUTH_KEY_ID
        rv = 91
        text = {<nsFixedString> = {<nsString> = {<nsAString_internal> = {
                mData = 0x7fff9cd6fd80, mLength = 13, mFlags = 
    65553}, <No data fields>}, mFixedCapacity = 63, mFixedBuf = 
    0x7fff9cd6fd80}, mStorage = {78, 111, 116, 32, 67, 114, 105, 116, 105, 
    99, 97, 108, 10, 0, 116, 104, 111, 114, 105, 116, 121, 32, 75, 101, 121, 
    32, 73, 100, 101, 110, 116, 105, 102, 105, 101, 114, 0, 102, 102, 32, 56, 
    57, 32, 55, 54, 32, 102, 100, 32, 55, 54, 32, 49, 100, 32, 99, 53, 32, 
    102, 101, 32, 0, 49, 0}}
        extensionItem = {<nsCOMPtr_base> = {mRawPtr = 
    0x7f8076ef51f0}, <No data fields>}
[...]

Comment 6

[Andrey Jivsov]

According to RFC 3280, AuthorirityKeyIdentifier follows the format of SubjectKeyIdentifier, explained in section "4.2.1.2  Subject Key Identifier":

"For CA certificates, subject key identifiers SHOULD be derived from the public key or a method that generates unique values." [and this SKI makes into AKI]. 

Note that any method that generates unique values is approved with SHOULD (while other methods are not strictly prohibited). I suspect that NSS expects the value to be one of "Two common methods" described in that section.

The value used in the attached certificate is 8 byte value derived from the hash of the public key (thus, it follows the blessed algorithm in general; the deviation is dictated by historic reasons and follows another RFC, but this is not relevant here.)

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

Thanks for the stack trace and other data.  
Despite the appearance of the letters NSS in the relevant function names,
this is not a crash in NSS code.  All the code in /mozilla/security/manager 
is part of a browser component named PSM, which does crypto security GUI 
for Mozilla products.  I will reassign this bug to the relevant PSM folks.

Comment 8

[Andrey Jivsov]

Nelson: FYI the comment #5 is a crash in Thunderbird.

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

That's fine.  PSM is common to Firefox and Thunderbird.

Comment 10

[Daniel Veditz [:dveditz]]

Are the first three attachments new test certs, or are they the same ones about which you said "Certificate content is omitted due to sensitive nature" in comment 0? Asking so we can flag them sensitive to prevent accidental disclosure.

Comment 11

[Andrey Jivsov]

The same as referred in comment #0. I added them after the approval in comment #1. First 3 attachments (*.pem, *.p12) correspond to the same cert and private key pair.

Comment 12

[Andrey Jivsov]

We now believe that AKI information in these certificates is encoded incorrectly. It is encoded as if IMPLICIT ASN.1 tag is missing. Thus, this bug asks to simply not crash when encountering this AKI. In other words, a reasonable action to take on this extension is to behave as if it was not present (it is not marked critical). I have no evidence that the shorter size mentioned in comment #6 have contributed to the crash.

openssl and Microsoft Internet Explorer not only avoid the crash, but are able to display this AKI.

Comment 13

[Daniel Veditz [:dveditz]]

This is a non-exploitable null dereference.

another orphan timeless patch, this one two years old :-(

Comment 14

[Daniel Veditz [:dveditz]]

I've hidden the attachments, but the subject in the cert was "A subject". When you say "sensitive" do you mean because they might reveal a security problem or because they reveal private key material? If it's just the former we can unhide them, and it would be nice to have a testcase for bug 529485. If it's the latter we will of course keep them private.

Because this one has a usable test cert I'm going to reopen this one and make it "depend on" the base bug instead.

Comment 15

[Andrey Jivsov]

There is no reason to hide the certs if this bug is made public. There is now sufficient information in the bug report to not need the certs. If the decision is made to open this bug, I have no problems making the certs public. [I was concerned that the vulnerability will become public prior to a fix].

I meant "exploitable" as in able to mount a DoS attack. An ability to crash network users by parsing a public cert is a fairly effective DoS. For example, broadcasting a https://xxx link (i.e. on a Website) or mass-mailing an SMIME-encrypted e-mail is all that takes for this DoS to reach many users.

Thank you for working on this.

Comment 16

[Kai Engert (:KaiE:)]

The patch in bug 529485 was checked in.