gcry_pk_hash_verify() does not work with explicitly specified hash algorithm
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	neverpanic
	Jul 6 2022, 4:26 PM

Description

gcry_pk_hash_verify() crashes when the data_tmpl argument does not contain a %s placeholder for the hash algorithm, but instead is explicitly specified.

This contradicts the documentation, which says:

See gcry_pk_hash_sign, for the explanation of handle for hash, data-tmpl and ctx.

The documentation for gcry_pk_hash_sign() says both methods are supported:

A template should include "(hash %s %b)" or "(hash ALGONAME %b)". For the former case, "%s" is substituted by the string of algorithm of gcry_md_get_algo (hd) and when gcry_md_read is called, ALGO=0 is used internally. For the latter case, hash algorithm by ALGONAME is used when gcry_md_read is called internally.

I'm attaching a reproducer for this issue:

test.c1 KBDownload

Details

Version: 66ef99bb1804d754edaa5d6b37651e92e918540e

Revisions and Commits

rC libgcrypt
	rCb2a64ed4f34a cipher: Fix gcry_pk_hash_verify for explicit hash.

Related Objects

Mentioned In: T7165: Release Libgcrypt 1.11.0
T5905: Release Libgcrypt 1.10.2
rC45a139b166a3: tests: Test gcry_pk_hash_sign w/explicit hash algo

Event Timeline

neverpanic created this task.Jul 6 2022, 4:26 PM

For the record, the valgrind trace for the crash is:

==407== Invalid read of size 2
==407==    at 0x484F410: memmove (vg_replace_strmem.c:1385)
==407==    by 0x487539B: UnknownInlinedFun (string_fortified.h:29)
==407==    by 0x487539B: do_vsexp_sscan.lto_priv.0 (sexp.c:1582)
==407==    by 0x48F298D: _gcry_sexp_build.constprop.0 (sexp.c:1805)
==407==    by 0x486CF58: UnknownInlinedFun (pubkey.c:659)
==407==    by 0x486CF58: gcry_pk_hash_verify (visibility.c:1049)
==407==    by 0x400C39: main (test.c:60)
==407==  Address 0x20 is not stack'd, malloc'd or (recently) free'd
==407==
==407==
==407== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==407==  Access not within mapped region at address 0x20
==407==    at 0x484F410: memmove (vg_replace_strmem.c:1385)
==407==    by 0x487539B: UnknownInlinedFun (string_fortified.h:29)
==407==    by 0x487539B: do_vsexp_sscan.lto_priv.0 (sexp.c:1582)
==407==    by 0x48F298D: _gcry_sexp_build.constprop.0 (sexp.c:1805)
==407==    by 0x486CF58: UnknownInlinedFun (pubkey.c:659)
==407==    by 0x486CF58: gcry_pk_hash_verify (visibility.c:1049)
==407==    by 0x400C39: main (test.c:60)
==407==  If you believe this happened as a result of a stack
==407==  overflow in your program's main thread (unlikely but
==407==  possible), you can try to increase the size of the
==407==  main thread stack using the --main-stacksize= flag.
==407==  The main thread stack size used in this run was 8388608.

• gniibe mentioned this in rC45a139b166a3: tests: Test gcry_pk_hash_sign w/explicit hash algo.Jul 7 2022, 4:47 AM