Chapter 11: Advanced Solaris Exploitation

Overview

This chapter will cover advanced Solaris exploitation using the dynamic linker. We will also cover the generation of encrypted shellcode, used for defeating Network IDS (Intrusion Detection System) and/or IPS (Intrusion Prevention System) devices.

Dynamic linking is explained extensively in the SPARC ABI. We advise you to go over the ABI manual, which can be found at www.sun.com/developers/tools/abi/solaris-abi.ps , for a better coverage of the concepts and to learn how dynamic linking works for various architectures and systems In this chapter, we will cover only the details necessary for constructing new exploitation methods in the Solaris/SPARC environment.

Overwriting Global Offset Table (GOT) entries to gain control of execution in Linux has been demonstrated and widely used in many public and private exploits. This technique is known to be the most robust and reliable way of exploitation of Write-to- anywhere -in-memory overflow primitives (such as format string bug, heap overflows, etc.). These vulnerabilities have all made use of the classic method of exploitation, namely overwriting the return address. The return address is stored in the thread stack and differs in various execution environments, which often leads to long brute force sessions in order to gather its location. For these reasons, altering the GOT in Linux and BSD OSes has been the best exploitation vector for various types of bug classes. Unfortunately, this technique is not possible on the Solaris/SPARC architecture, because dynamic linking works in a totally different manner. On SPARC, the GOT does not contain any direct references to the symbol's actual virtual address in the object. We'll refer to the function (such as printf ) as the symbol and the dynamic library (such as libc.so ), which is mapped into a thread's address space as object.

For the Solaris/SPARC architecture, let's assume that we are dealing with lazy binding. In lazy binding, symbols will be resolved by the linker on demand, not at the execution startup. No need to worry ”lazy binding is the default behavior. The Procedure Linkage Table (PLT) does all the necessary work to locate a symbol's address in any of the memory mapped objects. The PLT will then pass control to the dynamic linker ( ld.so.1 in Solaris) for an initial request for any symbol that is referenced in any of the object's .text segments, with an offset describing the symbol.

Note  

We aren't dealing with the name of the symbol, rather an offset that represents the location of the symbol within PLT. It is a subtle difference that can have a profound effect on exploitation.

Symbol resolution takes place via the dynamic linker walking through a linked list of mapped object structures. It then searches each object's dynamic symbol ( .dynsym ) table with the help of hash and chain tables. The hash and chain tables verify that the request has been satisfied by looking at the object's dynamic string ( .dynstr ) table.

The dynamic string table contains the actual string and name of the symbol. The linker simply does a string compare to determine whether the request is matched by the proper entry in the correct object. If the string is not matched and the chain table does not have any further entries, the linker moves to the next object in the link list and will keep going until the request has been satisfied.

After the symbol is resolved, or located, dynamic linker patches the PLT entry of the requested symbol with instructions. These newly patched instructions will make the application jump to the symbol's reallocation if and when it is subsequently requested . This is nice, because we won't need to do this crazy dynamic linking process all over again. Unlike the Linux glibc dynamic linker implementation, which updates the GOT entry for the symbol with the newly resolved location, the Solaris dynamic linker patches the PLT with actual instructions. These instructions will take the application directly to the location within the mapped object's text segment. You should remain fully aware of this major difference between Linux on x86 and Solaris on SPARC for future exploit construction sessions.

Since the PLT is patched with instructions (we're talking opcodes here, not addresses), altering any entry with an address pointing to shellcode will not be successful. Consequently, we prefer to overwrite the PLT with actual instructions. Unfortunately, this is not always possible, because the jump or call instruction displacement is relative to its current location. As you can imagine, locating the shellcode's relative distance from the overwritten PLT entry is not easy. With heap overflows, you will not be able to overwrite any arbitrary PLT entry, because both of the long integers that you are placing in memory need to be valid addresses within the thread's address space. If you have forgotten how to do this, check out Chapter 5 on heap overflows with Linux.



The Shellcoder's Handbook. Discovering and Exploiting Security
Hacking Ubuntu: Serious Hacks Mods and Customizations (ExtremeTech)
ISBN: N/A
EAN: 2147483647
Year: 2003
Pages: 198
Authors: Neal Krawetz

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net