Remote heap overflow.<\/p>\n
The description and source code can be found here: Ok, so the title here is a little misleading as I don’t actually have a solution. What I will<\/em> be doing, is explaining why this isn’t exploitable.<\/p>\n The predecessor to Phoenix<\/strong> is Protostar<\/a><\/strong>. This level is the same as Protostar’s Final Two<\/a><\/strong> level, yet that one IS exploitable despite the code being almost the same. I’ll discuss what makes Protostar different at the binary level.<\/p>\n Let’s have a look at the source code to see what the program does (spoiler alert: Nothing useful).<\/p>\n There’s not much in main()<\/span>. It just prints the banner, flushes anything in the input buffer (preventing you from piping anything to netcat), and calls get_requests()<\/span>.<\/p>\n The get_requests() <\/span>function is where it gets interesting. It sets up a while loop that will break after 256 iterations in order to accept “requests” from a user (up to 256 of them). That loop does a few things:<\/p>\n At this point, the get_requests() <\/span>function isn’t over, but let’s jump to check_path() <\/span>and come back to this later.<\/p>\n check_path() <\/span>will do several things:<\/p>\n Finally, back at the get_requests() <\/span>function, there’s a for loop that iterates for the number of 128 byte requests that were supplied by the user. The string “Process OK” is printed and free() <\/span>is called on each pointer in the destroylist[] <\/span>character pointer array.<\/p>\n If, at this point, you’re wondering, “when did we save any pointers to the destroylist[] <\/span>character pointer array?” Then you’re on the right track. This whole “heap overflow” attack relies on the free() <\/span>function. We would need to add an extra line of code to get_requests()<\/span>, like so:<\/p>\n There’s not much to it, but I’ll show an example of what “valid” input looks like:<\/p>\n To show what invalid input looks like, I’ll run the binary in GDB so we can see that it segfaults and at which instruction:<\/p>\n This happens because of the following line of code in the check_path() <\/span>function.<\/p>\n Since there is no “\/” character before the “ROOT” string, it keeps decrementing the point until it reaches a memory location it can’t read from. In this case, that’s at 0xf7e68fff, which is one byte before the start of the heap.<\/p>\n Now, if the free() <\/span>function was being called on our allocated heap chunks, we could take advantage of this bug and overwrite the chunk metadata for one of the requests. For more details on how to exploit a heap overflow with this, see my solution to the Heap Three<\/a><\/strong> level.<\/p>\n If you look at the source code from the get_requests() <\/span>function from Protostar’s<\/strong> Final Two level, it’s almost exactly the same. However, that one IS exploitable. There seems to be a difference between the source code and the binary. Let’s take a look at the binary on Protostar<\/strong>:<\/p>\n When the calloc() <\/span>function returns, it saves the pointer to the allocated heap space in EAX (get_requests+40). That pointer is saved to the stack at “ebp-0x14” (get_requests+45), which is where the buf<\/strong> variable is saved. This is then saved to EDX (get_requests+51). Finally, that pointer to the heap is stored in the character pointer array, with EAX containing the index number (get_requests+54). Each pointer in the array is 4 bytes in length, so the “eax*4” is a giveaway that it’s accessing the only array, destroylist[]<\/span>. That value is later used as an argument to the free() <\/span>function when it’s put onto the top of the stack (get_requests+194 & get_requests+201).<\/p>\n What this tells me, is that there is<\/em> a line in the source code that looks something like destroylist[dll] = buf; <\/span>My guess is that level was originally created with the source code you see, then updated when the author realized the level wasn’t exploitable and forgot to update the source code on the website. Now that Protostar<\/strong> has turned into Phoenix<\/strong>, the author of Phoenix used the non-exploitable version of the Final Two level.<\/p>\n I included all of the instructions up until the call to read() <\/span>(get_requests+86) in that last disassembly because that’s what I’ll show you in the final-two<\/strong> binary from Phoenix<\/strong>.<\/p>\n As you can see, the pointer that’s returned by the calloc() <\/span>function (stored in EAX) is saved to the buf<\/strong> variable, which is stored on the stack at “ebp-0x14” (get_requests+43). However, nothing else is done with that value until it’s pushed onto the stack (get_requests+54) as an argument for the call to read() <\/span>(get_requests+60). Later in the function during the for loop, the values in the destroylist[] <\/span>array are pushed onto the stack to be passed to free() <\/span>as parameters (get_requests+163 & get_requests+173). However, nothing was ever stored there.<\/p>\n Maybe it’s just my lack of experience, but it doesn’t seem this level is exploitable. I believe the intended method is for the attacker to send 2 requests, the first one being a valid request while the second one is missing a “\/” character before the “ROOT” string. After the “ROOT” string, you would have a “\/” character followed by values to overwrite the prev_size<\/strong> and size<\/strong> metadata for the second chunk. After that, you could include pointer values to be able to arbitrarily overwrite (almost) any location with (almost) any value, 4 bytes long, of course. Everything after that last “\/” character in the second request would get copied to the first request after the last “\/” character.<\/p>\n Again, for more details on how this is done and why it works, see my solution to the Heap Three<\/a><\/strong> level.<\/p>\n","protected":false},"excerpt":{"rendered":"
\nhttp:\/\/exploit.education\/phoenix\/final-two\/<\/a><\/p>\nSource Code Analysis<\/h1>\n
\r\nint main(int argc, char **argv, char **envp) {\r\n printf("%s\\n", BANNER);\r\n fflush(stdout);\r\n\r\n get_requests(0, 1);\r\n return 0;\r\n}\r\n<\/pre>\n\n
\n
\r\nvoid get_requests(int in_fd, int out_fd) {\r\n char *buf;\r\n char *destroylist[256];\r\n int dll;\r\n int i;\r\n\r\n dll = 0;\r\n while (1) {\r\n if (dll >= 255) break;\r\n\r\n buf = calloc(REQSZ, 1);\r\n if (read(in_fd, buf, REQSZ) != REQSZ) break;\r\n\r\n if (strncmp(buf, "FSRD", 4) != 0) break;\r\n\r\n check_path(buf + 4);\r\n\r\n dll++;\r\n }\r\n ...\r\n<\/pre>\n\n
\n
\n
\r\nvoid check_path(char *buf) {\r\n char *start;\r\n char *p;\r\n int l;\r\n\r\n \/*\r\n * Work out old software bug\r\n *\/\r\n\r\n p = rindex(buf, '\/');\r\n l = strlen(p);\r\n if (p) {\r\n start = strstr(buf, "ROOT");\r\n if (start) {\r\n while (*start != '\/') start--;\r\n memmove(start, p, l);\r\n }\r\n }\r\n}\r\n<\/pre>\n\r\n ...\r\n for (i = 0; i < dll; i++) {\r\n write(out_fd, "Process OK\\n", strlen("Process OK\\n"));\r\n free(destroylist[i]);\r\n }\r\n}\r\n<\/pre>\n\r\nvoid get_requests(int in_fd, int out_fd) {\r\n char *buf;\r\n char *destroylist[256];\r\n int dll;\r\n int i;\r\n\r\n dll = 0;\r\n while (1) {\r\n if (dll >= 255) break;\r\n\r\n buf = calloc(REQSZ, 1);\r\n destroylist[dll] = buf;\r\n if (read(in_fd, buf, REQSZ) != REQSZ) break;\r\n\r\n if (strncmp(buf, "FSRD", 4) != 0) break;\r\n\r\n check_path(buf + 4);\r\n\r\n dll++;\r\n }\r\n ...\r\n<\/pre>\nRunning the Program<\/h1>\n
\r\nuser@phoenix-amd64:~$ nc 127.1 64015\r\nWelcome to phoenix\/final-two, brought to you by https:\/\/exploit.education\r\nFSRD\/ROOT\/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\r\nFSRD\/ROOT\/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\r\nFSRD\/ROOT\/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\r\n\r\nProcess OK\r\nProcess OK\r\nProcess OK\r\n<\/pre>\n
\r\nuser@phoenix-amd64:~$ gdb -q \/opt\/phoenix\/i486\/final-two\r\nGEF for linux ready, type `gef' to start, `gef config' to configure\r\n71 commands loaded for GDB 8.2.1 using Python engine 3.5\r\n[*] 2 commands could not be loaded, run `gef missing` to know why.\r\nReading symbols from \/opt\/phoenix\/i486\/final-two...(no debugging symbols found)...done.\r\n\r\ngef> run\r\nStarting program: \/opt\/phoenix\/i486\/final-two\r\nWelcome to phoenix\/final-two, brought to you by https:\/\/exploit.education\r\nFSRDROOT\/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\r\n\r\nProgram received signal SIGSEGV, Segmentation fault.\r\n0x08048959 in check_path ()\r\n[... GEF output snipped ...]\r\n\r\ngef> x\/i $eip\r\n=> 0x8048959 <check_path+84>: mov al,BYTE PTR [eax]\r\n\r\ngef> x $eax\r\n 0xf7e68fff: Cannot access memory at address 0xf7e68fff\r\n<\/pre>\n
while (*start != '\/') start--;<\/pre>\n
Binary Analysis<\/h1>\n
\r\nuser@protostar:\/opt\/protostar\/bin$ gdb -q final2\r\nReading symbols from \/opt\/protostar\/bin\/final2...done.\r\n\r\n(gdb) set disassembly-flavor intel\r\n\r\n(gdb) disas get_requests\r\nDump of assembler code for function get_requests:\r\n...\r\n0x0804bd6f <get_requests+40>: call 0x804b4ee <calloc>\r\n0x0804bd74 <get_requests+45>: mov DWORD PTR [ebp-0x14],eax\r\n0x0804bd77 <get_requests+48>: mov eax,DWORD PTR [ebp-0x10]\r\n0x0804bd7a <get_requests+51>: mov edx,DWORD PTR [ebp-0x14]\r\n0x0804bd7d <get_requests+54>: mov DWORD PTR [ebp+eax*4-0x414],edx\r\n0x0804bd84 <get_requests+61>: add DWORD PTR [ebp-0x10],0x1\r\n0x0804bd88 <get_requests+65>: mov DWORD PTR [esp+0x8],0x80\r\n0x0804bd90 <get_requests+73>: mov eax,DWORD PTR [ebp-0x14]\r\n0x0804bd93 <get_requests+76>: mov DWORD PTR [esp+0x4],eax\r\n0x0804bd97 <get_requests+80>: mov eax,DWORD PTR [ebp+0x8]\r\n0x0804bd9a <get_requests+83>: mov DWORD PTR [esp],eax\r\n0x0804bd9d <get_requests+86>: call 0x8048e5c <read@plt>\r\n...\r\n0x0804be09 <get_requests+194>: mov eax,DWORD PTR [ebp+eax*4-0x414]\r\n0x0804be10 <get_requests+201>: mov DWORD PTR [esp],eax\r\n0x0804be13 <get_requests+204>: call 0x804a9c2 <free>\r\n...\r\n<\/pre>\n
\r\nuser@phoenix-amd64:\/opt\/phoenix\/i486$ gdb -q final-two\r\nGEF for linux ready, type `gef' to start, `gef config' to configure\r\n71 commands loaded for GDB 8.2.1 using Python engine 3.5\r\n[*] 2 commands could not be loaded, run `gef missing` to know why.\r\nReading symbols from final-two...(no debugging symbols found)...done.\r\n\r\ngef> disas get_requests\r\nDump of assembler code for function get_requests:\r\n ...\r\n 0x0804899a <+35>: call 0x804a53a <calloc>\r\n 0x0804899f <+40>: add esp,0x10\r\n 0x080489a2 <+43>: mov DWORD PTR [ebp-0x14],eax\r\n 0x080489a5 <+46>: sub esp,0x4\r\n 0x080489a8 <+49>: push 0x80\r\n 0x080489ad <+54>: push DWORD PTR [ebp-0x14]\r\n 0x080489b0 <+57>: push DWORD PTR [ebp+0x8]\r\n 0x080489b3 <+60>: call 0x8048700 <read@plt>\r\n ...\r\n 0x08048a1a <+163>: mov eax,DWORD PTR [ebp+eax*4-0x414]\r\n 0x08048a21 <+170>: sub esp,0xc\r\n 0x08048a24 <+173>: push eax\r\n 0x08048a25 <+174>: call 0x8049a12 <free>\r\n ...\r\n<\/pre>\n
Conclusion<\/h1>\n