Other Solaris Exploitation Techniques

There are a few remaining important techniques concerning Solaris-based systems that we should discuss. One, which you are highly likely to run into, is a non-executable stack. These protections can be overcome , both on Solaris and other OSes, so let's take a look at how to do it.

Static Data Overflows

Overflows that occur in static data rather than on the heap or stack are often more tricky to exploit. They often must be evaluated on a case-by-case basis, and binaries must be examined in order to locate useful variables near the target buffer in static memory. The organization of static variables in a binary is not always made obvious by examining the source code, and binary analysis is the only reliable and effective way to determine what you're overflowing into. There are some standard techniques that have proven useful in the past for exploiting static data overflows.

If your target buffer is truly within the .data section and not within the .bss , it may be possible to overflow past the bounds of your buffer and into the .dtors section where a stop function pointer is located. This function pointer is called when the program exits. Provided that no data was overwritten that caused the program to crash before exit() , when the program exits the overwritten stop function pointer will be called executing arbitrary code.

If your buffer is uninitialized and is located within the .bss section, your options include overwriting some program-specific data within the .bss section, or overflowing out of .bss and overwriting the heap.

Bypassing the Non-Executable Stack Protection

Modern Solaris operating systems ship with an option that makes the stack non-executable. Any attempt to execute code on the stack will result in an access violation and the affected program will crash. This protection has not been extended to the heap or static data areas however. In most cases this protection is only a minor obstacle to exploitation.

It is sometimes possible to store shellcode on the heap or in some other writable region of memory, and then redirect execution to that address. In this case the non-executable stack protection will be of no consequence. This may not be possible if the overflow is the result of a string-copy operation, because a heap address will most often contain a null byte. In this case, a variant of the return to libc technique invented by John McDonald may be useful. He described a way of chaining library calls by creating fake stack frames with the necessary function arguments. For example, if you wanted to call the libc functions setuid followed by exec , you would create a stack frame containing the correct arguments for the first function setuid in the input registers, and return or redirect execution to setuid within libc.so.1 . However, instead of executing code directly from the beginning of setuid , you would execute code within the function after the save instruction. This prevents the overwriting of input registers, and the function arguments are taken from the current state of the input registers, which will be controlled by you via a constructed stack frame. The stack frame you create should load the correct arguments for setuid into the input registers. It should also contain a frame pointer that links to another set of saved registers set up specifically for exec . The saved program counter ( %i7 ) within the stack frame should be that of exec plus 4 bytes, skipping the save instruction there as well.

When setuid is executed, it will return to exec and restore the saved registers from the next stack frame. It is possible to chain multiple library functions together in this manner, and specify fully their arguments, thus bypassing the non-executable stack protection. However, it is necessary to know the specific location of library functions as well as the specific location of your stack frames in order to link them. This makes this attack quite useful for local exploits or exploits that are repeatable and for which you know specifics about the system you are exploiting. For anything else, this technique may be limited in usefulness .