Page MenuHome GnuPG

parse_key doesn't check for EOF when listing packets
Closed, ResolvedPublic

Description

parse_key doesn't check for EOF when it encounters an RFC1991 comment packet when
listing packets. This results in it emitting a large number (up to ~ 2^33) of 'F'
characters on listing a packet with negligible length.

The trivial patch to fix this is inline; a test-case is included in the tarball
attached.

This bug was found by Michał Zalewski's american-fuzzy-lop; it has been replicated with
the version of GnuPG 1.4.18 packaged with Ubuntu 14.04 x86/x86_64, as well as against
versions built directly from GnuPG 1.4.18 source tarballs on Ubuntu 14.04 x86/x86_64
and OSX.

From 7239d8e562e14e05ce83b0b9ca6d9900af5285d7 Mon Sep 17 00:00:00 2001
From: David Leon Gil <coruus@gmail.com>
Date: Wed, 10 Sep 2014 12:40:54 -0400
Subject: [PATCH] Fix failure to check for EOF in parse_key.

---

g10/parse-packet.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/g10/parse-packet.c b/g10/parse-packet.c
index 92fc399..888a280 100644

  • a/g10/parse-packet.c

+++ b/g10/parse-packet.c
@@ -1631,7 +1631,9 @@ parse_key( IOBUF inp, int pkttype, unsigned long pktlen,

	    fprintf (listfp, ":rfc1991 comment packet: \"" );
	    for( ; pktlen; pktlen-- ) {
		int c;
  • c = iobuf_get_noeof(inp);

+ c = iobuf_get(inp);
+ if( c == -1)
+ break;

		if( c >= ' ' && c <= 'z' )
		    putc (c, listfp);
		else

1.8.5.2 (Apple Git-48)

Details

Version
1.4

Event Timeline

coruus added a subscriber: coruus.

A bogus packet which is shorter than announced by the packet header.
There are many ways of creating bogus packets and keep gpg processing data. In
particular compressed data can create arbitrary long output. Fixing this in old
branches creates the risk of regressions.

I will fix that for master, though.

werner claimed this task.

My one concern: Some programs in languages with implicit memory management
(Python, Vala) seem to use --list-packets to provide a 'detail view' of
keys etc. On 32-bit platforms, they'll try to allocate > 2^32 bytes of
memory to process a packet composition << 100 bytes; this will cause them
to crash.

Similar, but more severe, problem for programs that shell out to GnuPG on
mobile platforms (e.g., Android). This can be used to deterministically
cause OS to kill client program with unhandleable signal -- which may leave
uncleaned memory regions containing private key data / passphrases.
Suggestion: Just comment out the printf; the contents of such a comment are
never important. Hard to see any loss from this. Seems to merit making it
into a 1.x.y point release at some point.

  • David

On Sep 11, 2014 10:35 AM, "Werner Koch via BTS" <gnupg@bugs.g10code.com
<javascript:_e(%7B%7D,'cvml','gnupg@bugs.g10code.com');>> wrote:

Werner Koch <wk@gnupg.org <javascript:_e(%7B%7D,'cvml','wk@gnupg.org');>>
added the comment:

A bogus packet which is shorter than announced by the packet header.
There are many ways of creating bogus packets and keep gpg processing
data. In
particular compressed data can create arbitrary long output. Fixing this
in old
branches creates the risk of regressions.

I will fix that for master, though.


status: unread -> chatting


g10 Code's BTS <gnupg@bugs.g10code.com
<javascript:_e(%7B%7D,'cvml','gnupg@bugs.g10code.com');>>
<T1714>


setrlimit is your friend - do it right before the exec.

Hmm, do we need a gpgme feature for this?

We now have a GPGME feature to list packets:

gpgme_op_keylist_from_data_start

that is definitely better than to use the --list-packets debug
helper.