With static
analysis in particular you face the task of determining exactly how to reach the vulnerable
code while the program is executing. Additional analysis followed by testing against
a running program is the only way to confirm that your static analysis is correct. Should
you provoke a crash using a fuzzer, you are still faced with the task of dissecting the
fuzzer input that caused the crash and understanding any crash dumps yielded by the
program you are analyzing. The fuzzer data needs to be dissected into the portions required
strictly for code path traversal, and the portions that actually generate an error
condition with the program.
Knowing that you can crash a program is a far cry from understanding exactly why the
program crashes. If you hope to provide any useful information to assist in patching
the software, it is important to gain as detailed an understanding as possible about the
nature of the problem. It would be nice to avoid this conversation:
Researcher: ???Hey, your software crashes when I do this??¦???
Vendor: ???Then don??™t do that!???
Gray Hat Hacking: The Ethical Hacker??™s Handbook
460
In favor of this one:
Researcher: ???Hey, you fail to validate the widget field in your octafloogaron
application, which results in a buffer overflow in function umptiphratz.
Pages:
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803