Points: 400 Solves: Category: Exploitation Description:
Part 1, The Vulnerability
First of two Exploitation challenges in SSCTF, this package contains 32bit binary and the server’s libc.so library. I will not go over every detail but only the vulnerability and exploitation parts. On start the binary displays a menu.
It’s a integer sorting function. Choosing the sort option we are asked for the number of integers to sort and than a sub-menu appears.
Each one of the sorting options are self-explanatory. The History option, shows us the previously sorted lists. The reload option moves us in the context of the chosen history list ID. To exploit this binary we are only interested in the sort (including the sort sub-menu) and reload.
Let’s see how the sort function works. By issuing the above commands, we have created a struct with the following elements.
Next to it, there is another struct of 2 elements. It is used to keep track of the current active list. Right now only the first element has a value, which is a pointer to the beginning of our first list (remember that because it’s going to be used for the exploitation part).
Just by playing around with the Sort Menu, we can notice a few interesting things. First, the main vulnerability which is accessing out of bound element because the indexes == len of the array, this allows us to access one additional element. We also see that we can’t access an index higher than the number of elements stored in list->number_of_elements.
The reload option takes list ID from the history, makes it as the current active list and moves us to the Sort Menu to perform some action on it. Behind the scenes however, the reload option takes the pointer that points to the beginning of the struct and uses it as a source for memcpy. It takes the first element and it does ((x + 1) « 2), it than uses the result as size for memcpy. The destination is just the next available space (not important in our case).
Part 2, The Exploit
So, what do we know so far? We know we can read/write @ the pointer of the struct. We also know that we can use that pointer via the reload function to be the source of memcpy and thus change the current active list to have data based on what we are going to copy to the destination. I know it sounds a bit confusing but this is what we are going to do.
- Leak the pointer to the struct
- Change the pointer to a location where we control data (this will be in the current struct, just different offset)
- Invoke reload so we copy the data we control into the new active list. This will allow us to control the first element in the new list, which is going to lift the indexing restrictions.
- Now that our active sort list is with a controlled number_of_elements, we can reference any offset in the whole binary. This is what gives us read/write to any address via the Sort Menu’s Query and Update number by index.
- Leak the address of strcmp
- Change strcmp with system
Knowing the plan of action and what each step with allow us to do should of cleared things for you :).
- Hope you liked it :), to be continue in pwn600