A good debugger
can be your best friend when trying to interpret the results of a program crash. More specifically
a debugger will give you the clearest picture of how your inputs have conspired
to crash an application. Whether an attached debugger captures the state of a program
when an exception occurs, or whether you have a core dump file that can be examined, a
debugger will give you the most comprehensive view of the state of the application
when the problem occurred. For this reason it is extremely important to understand
what a debugger is capable of telling you and how to interpret that information.
NOTE We use the term exception to refer to a potentially unrecoverable
operation in a program that may cause that program to terminate
unexpectedly. Division by zero is one such exceptional condition. A more
common exception occurs when a program attempts to access a memory
location that it has no rights to access, often resulting in a segmentation fault (segfault).
When you cause a program to read or write to unexpected memory locations, you have
the beginnings of a potentially exploitable condition.
With a debugger snapshot in hand, what are the types of things that you should be
looking for? Some of the items that we will discuss further include
??? Did the program reference an unexpected memory location and why?
??? Does input that we provided appear in unexpected places?
??? Do any CPU registers contain user-supplied input data?
??? Do any CPU registers point to user-supplied data?
??? Was the program performing a read or write when it crashed?
Initial Analysis
Why did the program crash? Where did the program crash? These are the first two questions
that need to be answered.
Pages:
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805