Heaps

When a DLL gets loaded, it calls an initialization function. This function often sets up its own heap using HeapCreate() and stores a global variable as a pointer to that heap so that future allocation operations can use it instead of the default heap. Most DLLs have a .data section in memory for storing global variables , and you will often find useful function pointers or data structures stored in that area. Because many DLLs are loaded, there are many heaps. With so many heaps to keep track of, heap corruption attacks can become quite confusing. In Linux, there is typically a single heap that can get corrupted, but in Windows, several heaps may get corrupted at once, which makes analyzing the situation much more complex. When a user calls malloc() in Win32, he or she is are actually using a function exported by msvcrt .dll , which then calls HeapAllocate() with msvcrt.dll 's private heap. You may be tempted to try to use the HeapValidate() function to analyze a heap corruption situation, but this function does not do anything useful.

The confusion generally occurs when you have finished exploiting a heap overflow and you want to call some Win32 API functions with your shellcode. Some of your functions will work and some will cause access violations inside RtlHeapFree() or RtlHeapAllocate , which may terminate the process before you've had a chance to take control. WinExec() and the like are notorious for not working with a corrupted heap.

Each process has a default heap. The default heap can be found with GetDefaultHeap() , although that heap is unlikely to be the one that got corrupted. An important thing to note is that heaps can grow across segments. For example, if you send enough data to IIS, you will notice it allocating segments in high-order memory ranges and using that to store your data. Manipulating memory this way may be a useful trick if you have a limited set of characters with which to overwrite the return address, and if you need to get away from the low-memory address of default heaps. For this reason, memory leaks in target programs can become quite useful, because they let you fill all the program's memory with your shellcode.

Heap overflows on Windows are about as easy to write as they are on Unix. Use the same basic techniques to exploit themif you're careful, you can even squeeze more than one write out of a heap overflow on Windows, which makes reliable exploitation much easier.

Threading

Windows supports threads in a way that Linux never has and probably won't until the 2.6 kernel. Threading allows one process to do multiple things, sharing a single memory space. Windows's kernel gives processor-time slices to threads, not processes. Linux does things with a "light-weight process" model, which is fairly weak; only when Linux Native Threads gets implemented will Linux be on stable thread footing with the rest of the modern OS world. Threads simply aren't as important a programming model under Linux for reasons that will become clear as the NT security structure is explained.

Threading is the reason for HRESULT . HRESULT , basically an integer value, is returned by almost all Win32 API calls. HRESULT can be either an error value or an OK value. If it is an error value, then you can get the specific error with GetLastError() , which retrieves a value from the thread's local storage. If you think about Unix's model, there's no way to differentiate one thread's errno from another. Win32 was designed from the ground up to be a threaded model.

Windows has no fork() (used to spawn a new process in Linux). Instead, CreateProcess() will spawn a new process that has its own memory space. This process can inherit any of the handles its parent has marked inheritable. However, the parent must then pass these handles to the child itself or have the child guess at their values (handles are typically small integers, like file handles).

Because almost all overflows occur in threads, the attacker never knows a valid stack address. This means the attacker almost always uses a return-into-libc trick (although using any DLL, not just libc or the equivalent) to gain control of execution.



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