Now I regret reporting so many different problems as a single ticket. Note that if possible
information leaks are the only thing we are concerned with, all the issues in this ticket can be
solved by systematically initializing dynamically allocated memory, so they have that in common.

This won't solve the problems that several inconsistent .crt files are in fact accepted as valid,
showing contents of the freshly initialized allocated memory in place of information that should have
come from the .crt file. I would much prefer fixing these logic errors individually so that use of
uninitialized memory can remain a useful symptom of other logic errors, but ultimately, this is your
choice to make.

Here is a fourth instance of use of uninitialized memory (uninitialized4.crt).

The tis-interpreter diagnostic is:

Certificate in `t.crt':

  serial....:

02

3A

83

  issuer....:

`CN=GeoTrust Global CA,O=GeoTrust Inc.,C=US'

  subject...:

`CN=Google Internet Authority G2,O=Google Inc,C=US'

  notBefore.:

2013-04-05 15:15:56

  notAfter..:

2016-12-31 23:59:59

  hash algo.: (null)

Extn: 2.5.29.35 at 517 with length 24

SubjectKeyIdentifier:

none
src/ber-help.c:213:[kernel] warning: accessing uninitialized left-value:

assert \initialized(buf);                  
stack: _ksba_ber_parse_tl :: src/cert.c:1836 <-
       _ksba_cert_get_auth_key_id :: src/visibility.c:280 <-
       ksba_cert_get_auth_key_id :: tests/cert-basic.c:190 <-
       list_extensions :: tests/cert-basic.c:546 <-
       one_file :: tests/cert-basic.c:593 <-
       main

src/ber-help.c:213:[kernel] warning: completely indeterminate value in mallocksba_malloc_l130_935 with offsets 4152 bits.

In order to make the use of uninitialized memory visible, apply the following patch:

~/instrumented/libksba-1.3.4$ diff -u src/ber-
ber-decoder.c ber-decoder.lo ber-dump ber-help.c ber-help.h ber-help.o
ber-decoder.h ber-decoder.o ber-dump.c ber-help.c~ ber-help.lo
pascal@TrustInSoft-Box-VII:~/instrumented/libksba-1.3.4$ diff -u src/ber-help.c{~,}

• src/ber-help.c~ 2016-05-03 18:12:09.000000000 +0200

+++ src/ber-help.c 2016-05-11 03:04:34.361037076 +0200
@@ -210,7 +210,7 @@

/* Get the tag */
if (!length)
  return premature_eof (ti);

• c = *buf++; length--;

+ c = *buf++; printf("|%02hhX|\n", c); length--;

   ti->buf[ti->nhdr++] = c;
   ti->class = (c & 0xc0) >> 6;

With the above instrumentation in place, the command "./tests/cert-basic uninitialized4.crt" shows:

Certificate in `uninitialized4.crt':

serial....: (#023A83#)
issuer....: `CN=GeoTrust Global CA,O=GeoTrust Inc.,C=US'
subject...: `CN=Google Internet Authority G2,O=Google Inc,C=US'
notBefore.: 2013-04-05 15:15:56
notAfter..: 2016-12-31 23:59:59
hash algo.: (null)

Extn: 2.5.29.35 at 517 with length 24
SubjectKeyIdentifier: none

cert-basic.c:219: ksba_cert_get_auth_key_id: Invalid certificate object
KeyUsage: Not specified
ExtKeyUsages: none
CertificatePolicies: none
cert-basic.c:557: expected EOF but got: BER error

The line |3E| indicates access to uninitialized memory.

Here is a third instance, much like the second one. As the read from uninitialized memory happens in append_ucs2_value(),
the uninitialized memory is harder to recognize in the output.

tis-interpreter information:

Certificate in `t.crt':

  serial....:

02

3A

83
src/dn.c:522:[kernel] warning: accessing uninitialized left-value:

assert \initialized(tmp_1);
(tmp_1 from s++)
stack: append_ucs2_value :: src/dn.c:619 <-
       append_atv :: src/dn.c:667 <-
       dn_to_str :: src/dn.c:692 <-
       _ksba_dn_to_str :: src/cert.c:609 <-
       get_name :: src/cert.c:744 <-
       _ksba_cert_get_issuer :: src/visibility.c:190 <-
       ksba_cert_get_issuer :: tests/cert-basic.c:424 <-
       one_file :: tests/cert-basic.c:593 <-
       main

src/dn.c:522:[kernel] warning: completely indeterminate value in mallocksba_malloc_l130_935 with offset 1384 bits.

The file oid_oob_big.crt would cause the function ksba_oid_to_str() to be called with a “length” argument of

3100166514561975041. This is what execution in tis-interpreter (in which allocations always succeed) shows:

…
48

83

A5

this is not going to end well: length=3100166514561975041

src/oid.c:105:[kernel] warning: out of bounds read. assert \valid_read(buf_0+n);

                  stack: _ksba_oid_to_str :: src/cert.c:1462 <-
                         _ksba_cert_get_ext_key_usages :: src/visibility.c:259 <-
                         ksba_cert_get_ext_key_usages :: tests/cert-basic.c:265 <-
                         list_extensions :: tests/cert-basic.c:545 <-
                         one_file :: tests/cert-basic.c:592 <-
                         main

“Fortunately”, for the file oid_oob_big.crt, execution of the program tests/cert-basic differs in that a memory
allocation fails:

$ ./tests/cert-basic ../../libksba-1.3.3/oid_oob_big.crt
Certificate in `../../libksba-1.3.3/oid_oob_big.crt':

serial....: (#04#)
issuer....: `1.2.840.113549.1.9.1=#696E73656375726540746573742E696E736563757265,CN=For Tests

Only,O=InsecureTestCertificate,C=de'

       aka: `<insecure@test.insecure>'
subject...: `1.2.840.113549.1.9.1=#696E73656375726540746573742E696E736563757265,CN=Insecure Server

Cert,O=InsecureTestCertificate,C=de'

       aka: `<insecure@test.insecure>'
notBefore.: 2001-08-17 08:46:24
notAfter..: 2006-08-16 08:46:24
hash algo.: 1.2.840.113549.1.1.4

Extn: 2.5.29.15 at 474 with length 4
Extn: 2.5.29.37 at 487 with length 12
Extn: 2.5.29.14 at 508 with length 22
Extn: 2.5.29.35 at 541 with length 145
Extn: 2.5.29.17 at 695 with length 26
Extn: 2.5.29.18 at 730 with length 26
Extn: 2.16.840.1.113730.1.1 at 771 with length 4
Extn: 2.16.840.1.113730.1.13 at 790 with length 47
SubjectKeyIdentifier: (#0234E2C906F6E0B44253BE04C0CBA7823A6DB509#)
AuthorityKeyIdentifier: 1.2.840.113549.1.9.1=#696E73656375726540746573742E696E736563757265,CN=For Tests
Only,O=InsecureTestCertificate,C=de

       serial: (#00#)
keyIdentifier: (#BF53438278D09EC380E51B67CA0500DFB94883A5#)

KeyUsage: digitalSignature keyEncipherment keyAgreement
cert-basic.c:271: ksba_cert_ext_key_usages failed: Cannot allocate memory
CertificatePolicies: none

Regardless, between themselves, the two files oid_oob_big.crt and oid_oob_small.crt shows that an attacker seems to have
many possibilities for crafting a malicious certificate that crashes in ksba_oid_to_str() called from
ksba_cert_get_ext_key_usages().