text:08049A1D push eax
.text:08049A1E call _getcwd
We see that the absolute path of the current working directory is copied into init_cwd,
and we receive a hint that the declared length of init_cwd is actually 1024 bytes, rather
than 1032 bytes as Figure 12-9 seems to indicate. The difference is because IDA displays
the actual stack layout as generated by the compiler, which occasionally includes padding
for various buffers. Using IDA allows you to see the exact layout of the stack frame,
while viewing the source code only shows you the suggested layout. How does the value
of init_cwd affect our attempt at overwriting the saved return address? We may not
always know what directory the find application has been started from, so we can??™t
always predict how long the init_cwd string will be. We need to overwrite the saved
return address with the address of our shellcode, so our shellcode offset needs to be
included in the long filename argument that we will use to cause the buffer overflow.We
need to know the length of init_cwd in order to properly align our offset within the filename.
Since we don??™t know it, can the vulnerability be reliably exploited? The answer is
to first include many copies of our offset to account for the unknown length of init_cwd
and, second, to conduct the attack in four separate UDP packets in which the byte alignment
of the filename is shifted by one byte in each successive packet.
Pages:
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545