1192323 - ASan: SEGV in sec_asn1d_free_child()

Status: RESOLVED DUPLICATE of bug 1202868

(NSS :: Libraries, defect)

Description

[Tyson Smith [:tsmith]]

Attachment: call_stack

Comment 1

[Tyson Smith [:tsmith]]

Attachment: test_case.der

Comment 2

[Dana Keeler (she/her) [:keeler]]

Mass cc to get some NSS eyes on these bugs.

Comment 3

[Ryan Sleevi]

Related to the needinfo on Bug 1177759, do you have documented what checkcert invocation you're using or test harness?

I'm having trouble with the attached test_case.der, as checkcert -v is yelling at me. If I give it an arbitrary issuer cert, it yakks that the cert "Does not appear to be X509 SIGNED data". If I give it the same cert as the issuer, it yakks that the issuer cert isn't valid X509 SIGNED data.

Comment 4

[Ryan Sleevi]

So this is another variation of Bug 1202868 , and is an issue with OCTET STRINGs that are CONSTRUCTED and mix definite and indefinite length.

With ASN.1 state debugging enabled (and compile errors fixed), and with the test harness from Bug 1185033

PLACE = duringEndOfContents, next byte = 0x00, 0x61300000db5b[0]
State: tmpl 0x7ff95fedd420, kind SEQUENCE duringSequence, expect 0x30 51
  State: tmpl 0x7ff95fedd480, kind OCTET_STRING duringConstructedString, expect 0x04 4
    State: tmpl 0x7ff95f4eecc0, kind OCTET_STRING  duringConstructedString, expect 0x04, indef 0
      State: tmpl 0x7ff95f4eecc0, kind OCTET_STRING  duringConstructedString, expect 0x04, indef 0
        State: tmpl 0x7ff95f4eecc0, kind OCTET_STRING  duringConstructedString, expect 0x04 4
          State: tmpl 0x7ff95f4eecc0, kind OCTET_STRING  duringConstructedString, expect 0x04, indef 0
            State: tmpl 0x7ff95f4eecc0, kind OCTET_STRING  duringConstructedString, expect 0x04, indef 0
              State: tmpl 0x7ff95f4eecc0, kind OCTET_STRING  duringConstructedString, expect 0x04 4
                State: tmpl 0x7ff95f4eecc0, kind OCTET_STRING  duringConstructedString, expect 0x04, indef 0
                  State: tmpl 0x7ff95f4eecc0, kind OCTET_STRING  duringConstructedString, expect 0x04 4
                    State: tmpl 0x7ff95f4eecc0, kind OCTET_STRING  duringConstructedString, expect 0x04, indef 0
                      STATE: tmpl 0x7ff95f4eecc0, kind OCTET_STRING  duringEndOfContents, expect 0x04 2
ASAN:DEADLYSIGNAL
=================================================================
==20316==ERROR: AddressSanitizer: SEGV on unknown address 0x1004ffff9005 (pc 0x7ff95f4c5cd9 bp 0x7ffcf09cfe30 sp 0x7ffcf09cfb40 T0)
    #0 0x7ff95f4c5cd8 in port_ArenaRelease /usr/local/google/home/sleevi/development/nss/nss/lib/util/secport.c:479:36
    #1 0x7ff95f4c69f1 in PORT_ArenaZRelease /usr/local/google/home/sleevi/development/nss/nss/lib/util/secport.c:529:5
    #2 0x7ff95f4b1ef7 in sec_asn1d_free_child /usr/local/google/home/sleevi/development/nss/nss/lib/util/secasn1d.c:1383:2
    #3 0x7ff95f4a45d1 in SEC_ASN1DecoderUpdate_Util /usr/local/google/home/sleevi/development/nss/nss/lib/util/secasn1d.c:2759:6
    #4 0x7ff95f4b4508 in SEC_ASN1Decode_Util /usr/local/google/home/sleevi/development/nss/nss/lib/util/secasn1d.c:2925:11
    #5 0x7ff95f4b460b in SEC_ASN1DecodeItem_Util /usr/local/google/home/sleevi/development/nss/nss/lib/util/secasn1d.c:2940:12
    #6 0x7ff95f85bb45 in PK11_ImportDERPrivateKeyInfoAndReturnKey /usr/local/google/home/sleevi/development/nss/nss/lib/pk11wrap/pk11pk12.c:234:10
    #7 0x4d1e7d in main /usr/local/google/home/sleevi/development/nss/nss/cmd/checkcert/checkcert.c:24:7
    #8 0x7ff95e56eec4 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4)
    #9 0x41a7b5 in _start (/usr/local/google/home/sleevi/development/nss/nss/cmd/checkcert/Linux3.13_x86_64_clang_glibc_PTH_64_DBG.OBJ/checkcert+0x41a7b5)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /usr/local/google/home/sleevi/development/nss/nss/lib/util/secport.c:479:36 in port_ArenaRelease
==20316==ABORTING


The test data itself is somewhat clear that NSS's ASN.1 parser is crazypants with indefinite encodings:
- We have an outer SEQUENCE with a definite length (69 bytes)
  - The first member is a primitive integer, length 1, value 0x00
  - The second member is a constructed SEQUENCE, of length 13
    - The first member of this sequence is an OBJECT ID of length 9
    - The second member of this sequence is a primitive OCTET STRING, length 0
  - The third member of this sequence is a CONSTRUCTED OCTET STRING, length 4
    - In this case, same as in Bug 1202868, the OCTET STRING is multiple substrings
    - The first substring is a OCTET STRING, of indefinite length. 2 bytes are spent encoding this, so 2 bytes remain.
      - [THIS IS WHERE IT SHOULD ERROR - 2 bytes remain, and the EOC doesn't happen here]

Encoding wise, this could likely be further simplified as an ASN.1 parse of an OCTET STRING

(Input is 6 bytes long)

0x24, 0x04 (CONSTRUCTED OCTET STRING, 4 bytes long)
  0x24, 0x80 (CONSTRUCTED OCTET STRING, indefinite)
    0x24, 0x00 (CONSTRUCTED OCTET STRING, 0 bytes long)

The above ASN.1 should yield a parse error, because of the absence of the EOC octet, because the input was only 6 bytes long.

Comment 5

[Tim Taubert [:ttaubert] (inactive)]

Attachment: checkcert.c

(In reply to Ryan Sleevi from comment #3)
> Related to the needinfo on Bug 1177759, do you have documented what
> checkcert invocation you're using or test harness?

We've been using the checkcert.c file I wrote a few weeks ago, basically just replace nss/cmd/checkcert/checkcert.c with that, recompile with ASan and then you should be able to reproduce this and all the other nss-fuzz bugs.

Comment 6

[Tyson Smith [:tsmith]]

This was found with a 64 bit build

Comment 7

[Matt Wobensmith [:mwobensmith][:matt:]]

David, is this worth renewed attention from someone?

Comment 8

[Dana Keeler (she/her) [:keeler]]

I can't reproduce this anymore. I agree with Ryan's analysis that this is essentially bug 1202868.