This is particularly true when you crash a program using a fuzzer. As
long as you recognize which portion of your fuzzing input ends up in eip and determine
a suitable place within the fuzzer input to embed your shellcode, you do not need to
understand the innerworkings of the program that led up to the exploitable condition.
However, from a defensive standpoint it is important that you understand as much as
you can about the problem in order to implement the best possible corrective measures,
which can include anything from firewall adjustments and intrusion detection signature
development, to software patches. Additionally, discovery of poor programming
practices in one location of a program should trigger code audits that may lead to the
discovery of similar problems in other portions of the program, other programs derived
from the same code base, or other programs authored by the same programmer.
From an offensive standpoint it is useful to know how much variation you can attain
in forming inputs to the vulnerable program. If a program is vulnerable across a wide
range of inputs, you will have much more freedom to modify your payloads with each
subsequent use, making it much more difficult to develop intrusion detection signatures
to recognize incoming attacks.
Pages:
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815