vancaho / avalanche

Automatically exported from code.google.com/p/avalanche
2 stars 0 forks source link

Avalanche 0.4 doesn't check the cause of crash of the tested application #6

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
Test environment:
Ubuntu 10.04 32 bit (2.6.32-33-generic i686 SMP) in Virtualbox OSE 4.0.4, 2 
core of i5-2500, 768 mb of RAM
Host OS: ubuntu 11.04 64 bit (2.6.38-10-generic x86_64 SMP)
compiler: gcc version 4.4.3

The tested tools version: 0.4 stable release

Open source application testing with known bugs
1. imagemagick-6.6.10  
(http://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=18136)
confirm: ./bin/convert ./test_image.png /tmp/x.png
convert: magick/splay-tree.c:883: GetValueFromSplayTree: Assertion `splay_tree 
!= (SplayTreeInfo *) ((void *)0)' failed.
Aborted (core dumped)

cmdline: ~/avalanche-0.4/bin/avalanche --filename=./test_image_2.png 
./bin/convert ./test_image_2.png /tmp/x.png

results: 8 exploits were found (false-positive, not reproduced  after), total 
640 iteration passed, avalanche finished without warnings. NO EXPECTED BUG FOUND

The result of crashes were out-of-memory cases but the tools detects it as real 
crashes.

Original issue reported on code.google.com by xeioexception on 22 Aug 2011 at 6:40

Attachments:

GoogleCodeExporter commented 8 years ago
Hello!

First of all, thanks for your feedback!

Avalanche identifies a crash each time a program terminated abnormally. We try 
to gather as much information about such situations as possible, but, 
unfortunately, cannot completely guarantee that this information is enough to 
identify the cause of termination. In rare cases (such as OOM situation you 
have encountered) we get false-positives.

Also, Avalanche keeps the size of all input files to be checked - that means 
that initial input test_image_2.png will never be enough to generate 
test_image.png exploit.

Original comment by m.k.erma...@gmail.com on 22 Aug 2011 at 12:54

GoogleCodeExporter commented 8 years ago
I propose some little improvement for such cases. Each instrumentation plugin 
(tracegrid or covgrind) should report it own status by, for example, by 
separate file to the main program. So the orchestra tool could differ failed 
plugin and failed application cases. 
As another variant would be the running of the tested application in a 
standalone mode with possible exploit. 

Original comment by xeioexception on 22 Aug 2011 at 1:08

GoogleCodeExporter commented 8 years ago
The return value of Valgrind will always be the return value of the simulated 
process - it can't be used to differ between plugin failures and application 
failures.

Standalone application runs were used in previous versions, but it was decided 
that they are ineffective.

Original comment by m.k.erma...@gmail.com on 23 Aug 2011 at 10:37

GoogleCodeExporter commented 8 years ago
Now "partially fixed" in revision 238. Warnings are added to exploit reports 
when no stack trace is available (possibly terminated with SIGKILL) and when 
terminated by signal from another process (not kernel).

Original comment by m.k.erma...@gmail.com on 25 Aug 2011 at 3:41