Exploits may not be found when standard string functions (string.h) are used

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Compile given source code and run avalanche on it with the given mask (mask) 
and initial input (str_seed).

What is the expected output? What do you see instead?

Avalanche should find an exploit for this program - input file containing the 
following sequence of bytes: 'E', 'E', 'L', 'F', '\0'. This sequence leads to a 
segmentation fault (can be tested with str_exploit). 

However, avalanche executes 12 iterations and no defect reports are generated.

Original issue reported on code.google.com by m.k.erma...@gmail.com on 22 Jun 2011 at 2:13

Attachments:

• mask
• str_seed
• str_exploit

[GoogleCodeExporter]

Avalanche fails to find an exploit for given source code because of the call to 
fputs  (string_test.c:28). Calling fputs leads to subsequent call to strlen.

In-depth analysis of avalanche work on string_test.c showed that strlen and 
other string functions cause tracegrind to generate incorrect STP declarations. 
Further investigation showed that this happens due to heavy optimization used 
in glibc strlen (and other string functions) implementation.
Several other valgrind tools (memcheck, drd) are also affected by this issue. 
For these tools the problem is solved by the replacement mechanism provided by 
valgrind core (see 
http://code.google.com/p/avalanche/source/browse/trunk/valgrind/memcheck/mc_repl
ace_strmem.c).

The corresponding replacements for string.h functions were added to tracegrind 
in revision 209 (see 
http://code.google.com/p/avalanche/source/browse/trunk/valgrind/tracegrind/tg_re
place_strmem.c) and fixed this issue.

Original comment by m.k.erma...@gmail.com on 22 Jun 2011 at 2:47

• Changed state: Fixed