Hello! This is my first post here! So, here's the problem: I'm following a nice book called Hacking - The Art Of Exploitation. I'm at the point in wich the string format vulnerability is being explained. I've learned how to do it and on a x32 system of mine: it worked flawlessly. But on my x64 Ubuntu, I can't make it work.

This is the code of the program wich I need to exploit:
I have to input a string witch begins with the memory location of test_val, then some %08x. that reads the shit in the stack of main, then a %n parameter where I find the written address which on the inputed string to change the value of test_val to the number of writen bytes.

Normaly i would have to input this to make it work:

kaos@ubuntu$ ./a.out $(printf "\x40\x56\x5f\x6a")%08x.%08x.%08x.%08x.%08x%n


The problem in the x64 system is that test_val is located at 0x601080 (3 bytes) and when I input $(printf "\x80\x10\x60\x00"), it seems that \x00 doesn't input anything, because I think it's related to NULL as a string end.
Thus, I got a segmentation error all the times that I try because the address isn't valid.

How can I inject that 00? Or how can I write the address to make it readable to the %n parameter? It's just impossible? Hope I've made myself understood!

If there's anything unclear I can answer all the questions!

Thanks!

Fortunately vulnerabilities aren't meant to be reliable. I'm also wondering how printing the address to standard output results in it being written to the stack right after printf's first argument, unless printf always has a stack-allocated output buffer at the beginning of the function.
Kevin Barry

PS It would be easier to just use an argument that's 1028 bytes long and overwrite test_val with strcpy, or if you're dead-set on %n use a string that writes past printf(text/*<--here*/); on the stack and write the address there (which could incidentally compromise the operation of strcpy, probably defeating your own effort).

Yo thx for the answer! I tought there was a method to print x00 with printf. No, I don't care about owning the program with the other overflows, because this was just an example. =) I'm just a little worried about all the times when I'll find adresses that start with 00.

You've got at least 3 things working against your attempt to pass 0x00 directly:

1. The shell (bash, anyway) will discard null characters:
   Code:

   $ value="$(printf '12\x0034')"
   $ echo ${#value} "$value"
   4 1234

2. execve will only read argument characters up until a null character:
   Code:

   #include <stdio.h>
   #include <unistd.h>
   
   
   static void show(char *oOne, char *tTwo)
   {
           fprintf(stderr, "%p:\t'%s'\n", oOne, oOne);
           fprintf(stderr, "%p:\t'%s'\n", tTwo, tTwo);
           fprintf(stderr, "[offset %i]\n", (int) (tTwo - oOne));
   }
   
   
   int main(int argc, char *argv[], char *envp[])
   {
           if (argc == 3)
           {
           show(argv[1], argv[2]);
           return 0;
           }
   
           char  arg1[] = "12\00034\000hello";
           char *arg2   = arg1 + 6;
   
           show(arg1, arg2);
   
           char *new_argv[] = { argv[0], arg1, arg2, NULL };
   
           execve(argv[0], new_argv, envp);
           return 1;
   }

   Code:

   $ ./a.out
   0x7fff23b85ae0: '12'
   0x7fff23b85ae6: 'hello'
   [offset 6] <-- 12\00034\000
   0x7fffb7406146: '12'
   0x7fffb7406149: 'hello'
   [offset 3] <-- not far enough apart for \00034\000 to be present

3. strcpy and printf will stop reading the string upon encountering a null character.

Kevin Barry

PS Ubuntu 64-bit uses 32-bit addresses, in case it wasn't obvious.

Thanks a lot for the proof! ^^ I'm glad I've been clarified!