[Announce] Security Alert for GnuPG 2.0 - Realloc bug in GPGSM

[Werner Koch]

Hi,

some more inforrmation about this bug

On Fri, 23 Jul 2010 14:36, wk at gnupg.org said:

> bug was found in GnuPG's GPGSM tool.  It is likely that this bug is
> exploitable by sending a special crafted signed message and having a

On a first view this might actually happen.  However, after some
thinking or well, taking a shower in the morning, I come to the
conclusion that writing an exploit for this bug is a too hard problem
for an entity of the Deep Though designed computer.

Here is what happens:

1. We parse each subjectAltName and convert it into a plain C string.
   This string is allocated on the heap and the address of that string
   (a pointer) is stored in an array.

2. That array has initially been allocated with space for 100 entries.
   The first two entries are used for the issuer and subject name and
   subjectAltNames are stored following them.

3. If the parser (step 1) wants to store the 99th subjectAltName string,
   the code detects that the array is full and uses realloc to
   reallocate the array with space for 100 more entries.  The 99th
   pointer is then stored in the next slot of the reallocated array.

4. The bug is that we did not complete the reallocation but continued to
   use the old array and may now write out of bounds.  Two cases may
   happen: The realloc function is able to extend the array, in which
   case no harm is done because the missing assignment of the new array
   would have been superfluous as it the same address.  The more likely
   case is that realloc allocates a new memory block, copies the old
   array to the new array and frees the old array.

5. Thus when writing the 99th subjectAltName string we write into freed
   space, which is a no-no.  We even write out of bounds in the freed
   space, so all kind of harm may happen.  This is always a severe bug
   which is likey to be expoitable.

Now, why do I think this is not exploitable: It is the simple fact that
the attacker can't control the value which is written into the freed
memory block.

The value we are writing comes from our own malloc which at that point
is working as expected because the entire heap has not yet been damaged
(modulo other bugs in the code of course).  Now the heap is corrupted
and all future calls mallocs or free may to weird things.  Usually you
will see a segv then.

To exploit it, an attacker needs to hope that an overwrite (using a
malloc returned pointer) does harmful things but doesn't stop the
execution and continues to parse his certificate.  One of the next
subjectAltName need to overwrite a function and set it to (already
existing) code which does the actual attack.

You may prove me wrong, but I dount that anyone will spend time on
finding such an exploit.  It would be much faster to look for other, not
yet known, bugs.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.