[Announce] Security Alert for GnuPG 2.0 - Realloc bug in GPGSM
wk at gnupg.org
Tue Jul 27 18:59:02 CEST 2010
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
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.
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
More information about the Gnupg-users