Mailing List Archive: gcry_sexp_find

Hello,

We have found that passing bad data for the "list" parameter to the function
gcry_sexp_find_token() can result in a segmentation fault. We are looking
at ways to prevent sending bad data to the function but we also want to
investigate ways to improve error checking in the function. The problem we
are seeing is that when the function scans through the bad data it may find
an ST_DATA (0x01) byte. When this happens the next two bytes are extracted
and used to increment "p". The next dereference of "p" may cause a seg
fault.

One thing we are considering doing to decrease the chances of a seg fault
occurring is to check the value of the first byte that "list" points to
prior to entering the while loop. Here's what we have in mind:

p = list->d;

if ((*p != ST_OPEN) && (*p != ST_DATA))
return NULL;

while (...

Could someone more knowledgeable about the library tell me whether doing
this will break the function?

Thank you,

Eric Bopp

On Tue, 7 Jun 2005 15:52:09 -0700 , Bopp, Eric said:

> gcry_sexp_find_token() can result in a segmentation fault. We are looking
> at ways to prevent sending bad data to the function but we also want to
> investigate ways to improve error checking in the function. The problem we

The really question here is how did it happen that you came up with
inconsistent data. LIST is an internalmobject of libgcrypt and thus
the actual must be somewhere in Libgcrypt at a place where LIST has
been created or modified.

> and used to increment "p". The next dereference of "p" may cause a seg

while ( *p != ST_STOP ) {
if ( *p == ST_OPEN && p[1] == ST_DATA ) {

Failing at p[1] we can conclude that the CLOSE token is missing.

> Could someone more knowledgeable about the library tell me whether doing
> this will break the function?

You would hide the real problem with such a workaround.

Salam-Shalom,

Werner