This most commonly occurs when we
have placed shellcode in the stack, and the shellcode utilizes the stack for temporary
storage, as may be the case for self-decoding shellcode. For example, if we inject
shellcode into the area named Vulnerable Buffer in Figure 18-6, then when the exploit is
triggered, esp will be pointing roughly at location E. If our shellcode pushes too many
variables, the stack will grow into the bottom of our shellcode with a high chance of corrupting
it. If, on the other hand, our shellcode is injected at or below E, then it will be
safe to push as much data as needed without overwriting any portion of our shellcode.
Clearly, this potential for corruption demands that we understand the exact behavior of
our shellcode and its potential for self-corruption. Unfortunately, the ease with which
we can generate standard payloads using tools such as Metasploit also makes it easy to
overlook this important aspect of shellcode behavior. A quick glance at the Metasploit
Linux findsock shellcode shows that the code pushes 36 bytes of data onto the stack.
Chapter 18: From Vulnerability to Exploit
477
PART IV
Figure 18-6
Potential
corruption of
stack variables
Gray Hat Hacking: The Ethical Hacker??™s Handbook
478
If you are not careful, this could easily corrupt shellcode placed in memory prior to the
saved eip location.
Pages:
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837