New gpg-error.m4 detects gpgrt-config, too.
And configure supplies --libdir when it invokes gpgrt-config.
For other *.m4 (libassuan, ksba, libgcrypt, ntbtls), it is possible for them to check GPGRT_CONFIG to use gpgrt-config if any.
For npth.m4, it can do that too, with no hard dependency to libgpg-error.

A bit tricky, but this would be good to use gpgrt-config by gpg-error.m4.
I say "tricky", because its name is gpg-error.m4 but it configure GPGRT_CONFIG to access to GPG_ERROR_CONFIG.

It might be good idea to provide libgcrypt.pc in libgcrypt 1.8.x for forward compatibility with libgpg-error 1.33.

Well, I changed my mind. Use of new gpgrt-config requires software update to introduce gpgrt.m4 and update of configure.ac to switch gpgrt from gpg-error, in standard way.
That's too much this time. It's good to defer this change.

OK, I'll change to use gpgrt-config, along with requiring newer version of libgpg-error.

May I suggest to use a (new) gpgrt-config instead of the current name libgpg-error-config. The long term plan is to change the name of the library.

This is the dependency graph:

Thanks.

Thanks. That code is from 2001 and whne I changed to another time representaion in 2003 (due certs with 40 years expiration time) I missed to changed that condition.

I was not aware that you could do this at all. You are right in that to start supporting this we first need to update libksba.

Please ignore them.

Fixed in a1d9b046aec8cedda16a9e24eb8d2ed021f68d5d

It is fine to close this. Reworking the parser is not going to happen anytime soon.

Because werner says he fixed the memory access, I am closing here. werner, if you want to keep track of the invalid encoding issue with the asn.1 parser, please open a new task with some details. pascal, if you find anything missing, please open new tickets (as you said, it's easier to keep track of issues in separate tickets).

Can you add a description?

Weel, required if you cange an .y file.

Bison is required.
I pushed a change which prints a note if yacc is not Bison.

I was unaware that the released version does not require it.

In that case it's no bug imo. because otherwise we would also need to work with
older autotools versions etc.

Bison is a maintainer tool and regualr builds do not require it.
I am also surprised that you can build it with a regular(?) yacc.

btw. reason for this report is a setup of WKS where you require most recent
modern gnupg on long time distro running servers.

You are right. Fixed with commit 68fba3d.

commit 2a9fc56 fixes the access to uninitialized buffers. Given that GnuPG puts
all senstive data into a special memory area which is cleared before a free, I
don't see a problem with a possible data leak.

What is left is the problem that the parser does not always detect invalid
encodings. This can be improved but I am not anymore convinced about that table
driven parser.

Thanks. I would actually prefer to handle this by mail because this makes
communication easier and faster. It would also be useful to known on what you
are working or plan to work on, so that we do not need to rush out releases
while there are other obvious things to fix.

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.

1.3.4 has been released.

1.3.4 has been released

I just released 1.3.4 and thus closing this bug and 2342 and 2343. Thanks again
for you help.

Fixed with commit 3f74c2c. Thanks.

The use in cert-basic is correct because get_oid_desc accepst a NULL pointer.
However, some libc versions bail out on a NULL for "%s"; I fixed that too.

Fixed with commit 6be61da.

The old fix for the problem from April 2015 had an off-by-one in the
bad encoding handling. Now using simpler code.

Fixed with commit a7eed17 . Thanks.

I also checked all other places to ensure that the tag length returned from
_ksba_ber_parse_tl is within the bounds.

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().

This has been fixed in libgpg-error and the gpg-error.m4 macros have been
updated in all gnupg related libraries.

No c+p of warnings please! Use gnupg-devel instead.

Use gnupg-devel for such things.

(If you want to provide a fix, please provide a diff and not the complete file.)