Note that the application remains as vulnerable as ever. A buffer of 528 bytes will still
overwrite the saved return address. A clever attacker might attempt to grow her buffer by
incrementally appending copies of her desired return address to the tail end of her
buffer, eventually stumbling across a proper buffer size to exploit our application. However,
as a final twist, it is worth noting that we have introduced several new obstacles that
the attacker must overcome. First, the location of buf has changed enough that any
return address chosen by the attacker may fail to properly land in the new location of
buf, thereby causing her to miss her shellcode. Second, the variables i and j now lie
beneath buf and will both be corrupted by the attacker??™s overflow. If the attacker??™s input
causes invalid values to be placed into either of these variables, we may see unexpected
behavior in badCode, which may cause the function to terminate in a manner not anticipated
by our attacker. In this case, i and j behave as makeshift stack canaries. Without
access to our mutated binary, the attacker will not understand that she must take special
care to maintain the integrity of both i and j. Finally, we could have allocated more stack
space in the prologue by subtracting 536 bytes, for example, and relocating buf to [ebp-
527].
Pages:
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864