String formatting exploit ends with segfault

Question

Now I'm reading the book Hacking - The Art of Exploitation.

This is my simplified version of the code for using formatted strings.

/* fmt_vuln.c */ #include <stdio.h> #include <stdlib.h> #include <string.h> int main (int argc, char *argv[]){ char text [1024]; if (argc < 2){ printf ("Usage: %s <text to print>\n", argv[0]); exit (0); } strcpy (text, argv[1]); printf ("The wrong way to print user-controlled input:\n"); printf (text); printf ("\n"); return 0; } 

I ran this command:

 ./fmt_vuln AAAA%08x.%08x.%08x.%08x.%08x.%08x.%08x.%08x 

I got:

 The wrong way to print user-controlled input: AAAA59055000.58e347a0.58b68620.ffffffff.00000000.fba56ac8.58a9fc58.41414141 

So, I saw that the parameter of the 8th format is read from the beginning of the format string.

Then, when I ran the command:

 ./getenv PATH ./fmt_vuln 

I received the address:

 0x7ffe2a673d84 

So, I tried to run: (to print the PATH variable)

 ./fmt_vuln $(printf "\x84\x3d\x67\x2a\xfe\x7f")%08x.%08x.%08x.%08x.%08x.%08x.%08x.%s 

I got:

 The wrong way to print user-controlled input: Segmentation fault 

Why did I get segfault? I got the PATH address from getenv, but the program still crashes ...

Rate the help.

Answer 1

Not all processes on a computer share the same memory space for security reasons. What do I mean when I talk about different spaces of memory? Consider the following 2 programs:

 //program 1 int main(int argc, char** argv){ printf("%02x", *((uint8_t*)0xf00fba11)); return 0; } //program 2 int main(int argc, char** argv){ printf("%02x", *((uint8_t*)0xf00fba11)); return 0; } 

If these programs should run simultaneously (and assuming they are not segfault (which they will almost certainly be)), they will print different values. How can it be?? They both access memory location 0xf00fba11! ... or are they?

To understand what is happening here, we first need to understand what happens when the processor loads a value from memory. To load a value from memory, the processor sends a request to RAM, for example:

  cpu |-------------| |---------| | read |-------address out to RAM (0xf00fba11)---->| RAM | | | | | | *0xf00fba11 |<---------data coming back to CPU----------| | |-------------| |---------| 

There is special hardware between the processor and the operator that translates addresses from "virtual addresses" to "physical addresses"; it is called a memory management unit ( MMU for short). If the program requests a value at address 0x1000, the MMU can "reassign" 0x1000 to 0x8000. If the address 0x1000 is always replaced by 0x8000 before it reaches RAM for all reads and writes, this may seem pointless. The program still works the exact same way ... so is this a significant deal?

The big deal is that now programs 1 and 2 cannot access other data. The MMU can be configured so that there is no address that program 1 can read from which it contains one of the variables of program 2. This “mapping” is unique to each process (basically) and is configured by the operating system.

Here is an example of how the MMU can affect our example "f00fba11".

 Process 1 cpu |-------------| |---------| | read |---0xf00fba11---| MMU |--0x1000ba11------->| RAM | | | | | | *0xf00fba11 |<---------data coming back to CPU----------| | |-------------| |---------| Process 2 cpu |-------------| |---------| | read |---0xf00fba11---| MMU |--0x7000ba11------->| RAM | | | | | | *0xf00fba11 |<---------data coming back to CPU----------| | |-------------| |---------| 

Both process 1 and process 2 requested data stored at memory address 0xf00fba11, but they were given 2 completely different memory cells! This brilliant invention is called "virtual memory." We say that 2 processes have different “address spaces” if the MMU displays its memories in different ways. The operating system solves these mappings and configures the MMU to comply, thereby "isolating" the processes from each other. Consider 2 processes and memory addresses that they can access.

 Process 1 asks for | gets physical address ------------------------------------ 0x0000 - 0x0fff | ERROR SEGFAULT 0x1000 - 0x1fff | 0x70000 - 0x70fff 0x2000 - 0x2fff | 0x30000 - 0x30fff 0x3000 - 0x3fff | 0xa7000 - 0xa7fff etc.... | etc..... Process 2 asks for | gets physical address ------------------------------------ 0x0000 - 0x0fff | ERROR SEGFAULT 0x1000 - 0x1fff | 0xb1000 - 0xb1fff 0x2000 - 0x2fff | 0x40000 - 0x40fff 0x3000 - 0x3fff | 0x1c000 - 0x1cfff etc.... | etc..... 

So, if the envrionment variable is loaded at memory address 0x7ffe2a673d84 in process 1, it can translate to the physical address 0x63002a673d84. Moreover, when process 2 tries to access * 0x7ff32a673d84, it will be mapped to a completely different address, or in your case it may be REQUIRED for process 2, which will lead to SEGFAULT.

So the bad news: I don’t think you can fix this problem with your code. Doing what you are trying to do will either give you segfault or random useless data. To get the data you are interested in, you need to look at the MMU configuration settings and change them, which you are not allowed to do if you are not working at an elevated privilege level.

Before we part, it is worth noting that there can be several common addresses between processes in order to transfer data between two processes or to access shared software libraries. That is, 0x1000 will translate to 0x5000 for several different processes.

Or maybe I have no idea what you're talking about. I really did not follow the line about ./getenv PATH ./fmt_vuln

Answer 2

You are using a 64-bit system, so your address has 8 bytes.

Look at this address 0x7ffe2a673d84 , it has only 6 bytes. This means that the two high bytes are zero. But you cannot just provide the null byte as a hexadecimal string, such as \xff\xaa\xbb\x00 , because the program will interpret this null byte as the end of the string.

You need to use a 32-bit system to experiment with this, the x64 architecture will not allow you to use this exploit.