Stay Ahead with the Power of Upskilling - Invest in Yourself! 
SEH
An exception is an event that occurs during the execution of a program, and requires the execution of code outside the normal flow of control. There are two kinds of exceptions: hardware exceptions and software exceptions. Hardware exceptions are initiated by the CPU. They can result from the execution of certain instruction sequences, such as division by zero or an attempt to access an invalid memory address. Software exceptions are initiated explicitly by applications or the operating system. For example, the system can detect when an invalid parameter value is specified.
Structured exception handling is a mechanism for handling both hardware and software exceptions. Therefore, your code will handle hardware and software exceptions identically. Structured exception handling enables you to have complete control over the handling of exceptions, provides support for debuggers, and is usable across all programming languages and machines. Vectored exception handling is an extension to structured exception handling.
The system also supports termination handling, which enables you to ensure that whenever a guarded body of code is executed, a specified block of termination code is also executed. The termination code is executed regardless of how the flow of control leaves the guarded body. For example, a termination handler can guarantee that clean-up tasks are performed even if an exception or some other error occurs while the guarded body of code is being executed.
The structured exception handling and termination handling mechanisms are integral parts of the system; they enable the system to be robust. You can use these mechanisms to create consistently robust and reliable applications.
Structured exception handling is made available primarily through compiler support. For example, the Microsoft C/C++ Optimizing Compiler supports the __try keyword that identifies a guarded body of code, the __except keyword that identifies an exception handler, and the __finally keyword that identifies a termination handler. Although this overview uses examples specific to the Microsoft C/C++ compiler, other compilers provide this support as well.
Vectored Exception Handling – Vectored exception handlers are an extension to structured exception handling. An application can register a function to watch or handle all exceptions for the application. Vectored handlers are not frame-based, therefore, you can add a handler that will be called regardless of where you are in a call frame. Vectored handlers are called in the order that they were added, after the debugger gets a first chance notification, but before the system begins unwinding the stack.
Microsoft’s Structured Exception Handling is a mechanism for handling hardware and software exceptions (both system and user defined), which allows recovering from errors and perform cleanup if necessary instead of terminating a program immediately.
The SEH represented as a linked list, whose records are stored on the stack. To ease access to this SEH chain, its head pointer maintained in Win32 Thread Information Block (TIB) structure. The TIB structure stores information about currently running thread. On x86 systems, the FS segment register points on TIB structure. SEH chain head located at offset 0x00, and therefore, you can refer to SEH chain head as FS:[0].
Each entry (_EXCEPTION_REGISTRATION_RECORD structure) consists from two 4-byte pointers:
- Pointer to the next exception registration record in the chain
- Pointer to the exception handling routine
The chain’s last record always contains 0xFFFFFFFF value as the “next entry” and pointer to OS default exception handler routine (located in ntdll.dll!FinalExceptionHandler)
Once the exception occurs, the runtime unwinds the stack and calls the exception handler routine associated with the first SEH entry. Exception handler should first decide what to do. It can handle the exception by itself (EXCEPTION_EXECUTE_HANDLER constant), pass the exception to next exception handler without doing anything (EXCEPTION_CONTINUE_SEARCH constant) or rerun the instruction that caused the exception (EXCEPTION_CONTINUE_EXECUTION constant). Once found appropriate handler that accepts to handle the exception, and the specified code executed, next statement after the exception handler block will be executed.
Structured Exception Handler (SEH) overwrite exploitation technique, exploits SEH and was publicly documented by David Litchfield of NGS Software in a research paper that he published in September, 2003. Since this publication, the SEH overwrite technique has become a standard weapon in an attacker’s arsenal. Roughly 20% of the exploits included in the latest version of the Metasploit framework make use of the SEH overwrite technique. SEH overwrites are also commonly used by exploits that target the increasing number of browser-based vulnerabilities.
At a high-level, the SEH overwrite technique uses a software vulnerability to execute arbitrary code by abusing the 32-bit exception dispatching facilities provided by Windows. At a functional level, an SEH overwrite is generally accomplished by using a stack-based buffer overflow to overwrite an exception registration record that has been stored on a thread’s stack. To provide some context, an exception registration record is composed of two fields: a next pointer and an exception handler function pointer. The next pointer is used to link an exception registration record to the next record in the singly-linked list of registered exception handlers. The exception handler function pointer is called by the Windows exception dispatcher when an exception occurs.
Data Execution Prevention
Data Execution Prevention (DEP) is a security feature included in modern operating systems. It marks areas of memory as either “executable” or “non-executable”, and allows only data in an “executable” area to be run by programs, services, device drivers, etc. It is known to be available in Linux, OS X, Microsoft Windows, iOS and Android operating systems.
DEP protects against some program errors, and helps prevent certain malicious exploits, especially attacks that store executable instructions in a data area via a buffer overflow. It does not protect against attacks that do not rely on execution of instructions in the data area. Other security features such as address space layout randomization, structured exception handler overwrite protection (SEHOP) and Mandatory Integrity Control, can be used in conjunction with DEP.
DEP runs in two modes: hardware-enforced DEP for CPUs that can mark memory pages as non-executable, and software-enforced DEP with limited protection for CPUs that do not have hardware support. Software-enforced DEP does not protect against execution of code in data pages, but counters SEH overwrite, another type of attack.
DEP was introduced on Linux in 2004 (kernel 2.6.8), on Windows in 2004 with Windows XP Service Pack 2, while Apple introduced DEP when they moved to x86 in 2006.
Data execution prevention (DEP) is a set of hardware and software technologies that perform additional checks on memory to help protect against malicious code exploits. In Windows XP SP2, DEP is enforced by both hardware and software.
Hardware-enforced DEP
Hardware-enforced DEP marks all memory locations in a process as non-executable unless the location explicitly contains executable code. There is a class of attacks that attempt to insert and execute code from non-executable memory locations. DEP helps prevent these attacks by intercepting them and raising an exception. Hardware-enforced DEP relies on processor hardware to mark memory with an attribute that indicates that code should not be executed from that memory. DEP functions on a per-virtual memory page basis, usually changing a bit in the page table entry (PTE) to mark the memory page.
The actual hardware implementation of DEP and marking of the virtual memory page varies by processor architecture. However, processors that support hardware-enforced DEP are capable of raising an exception when code is executed from a page marked with the appropriate attribute set.
Physical Address Extension (PAE) mode – Beginning with Windows XP Service Pack 2, the 32-bit version of Windows utilizes the no-execute page-protection (NX) processor feature as defined by AMD or the Execute Disable bit feature as defined by Intel. In order to use these processor features, the processor must be running in Physical Address Extension (PAE) mode. The 64-bit versions of Windows XP uses the NX processor feature on 64-bit extensions and certain values of the access rights page table entry (PTE) field on IPF processors.
It is hoped that all future 32-bit and 64-bit processors will provide support for hardware-enforced data execution prevention. Microsoft continues to work with processor vendors to encourage the adoption and development of DEP technologies.
Software-enforced DEP
An additional set of data execution prevention security checks have been added to Windows XP SP2. These checks, known as software-enforced DEP, are designed to mitigate exploits of exception handling mechanisms in Windows. Software-enforced DEP runs on any processor which is capable of running Windows XP SP2. By default, software-enforced DEP only protects limited system binaries, regardless of the hardware-enforced DEP capabilities of the processor.
ASLR
Address space layout randomization (ASLR) is a computer security technique involved in protection from buffer overflow attacks. In order to prevent an attacker from reliably jumping to, for example, a particular exploited function in memory, ASLR randomly arranges the address space positions of key data areas of a process, including the base of the executable and the positions of the stack, heap and libraries.
Address space randomization hinders some types of security attacks by making it more difficult for an attacker to predict target addresses. For example, attackers trying to execute return-to-libc attacks must locate the code to be executed, while other attackers trying to execute shellcode injected on the stack have to find the stack first. In both cases, the system obscures related memory-addresses from the attackers. These values have to be guessed, and a mistaken guess is not usually recoverable due to the application crashing.
Address space layout randomization is based upon the low chance of an attacker guessing the locations of randomly placed areas. Security is increased by increasing the search space. Thus, address space randomization is more effective when more entropy is present in the random offsets. Entropy is increased by either raising the amount of virtual memory area space over which the randomization occurs or reducing the period over which the randomization occurs. The period is typically implemented as small as possible, so most systems must increase VMA space randomization.
To defeat the randomization, attackers must successfully guess the positions of all areas they wish to attack. For data areas such as stack and heap, where custom code or useful data can be loaded, more than one state can be attacked by using NOP slides for code or repeated copies of data. This allows an attack to succeed if the area is randomized to one of a handful of values. In contrast, code areas such as library base and main executable need to be discovered exactly. Often these areas are mixed, for example stack frames are injected onto the stack and a library is returned into.
Microsoft’s Windows Vista (released January 2007) and later have ASLR enabled for only those executables and dynamic link libraries specifically linked to be ASLR-enabled. For compatibility, it is not enabled by default for other applications. Typically, only older software is incompatible and ASLR can be fully enabled by editing a registry entry “HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\MoveImages”, or by installing Microsoft’s Enhanced Mitigation Experience Toolkit.
The locations of the heap, stack, Process Environment Block, and Thread Environment Block are also randomized. A security whitepaper from Symantec noted that ASLR in 32-bit Windows Vista may not be as robust as expected, and Microsoft has acknowledged a weakness in its implementation.
Host-based intrusion prevention systems such as WehnTrust and Ozone also offer ASLR for Windows XP and Windows Server 2003 operating systems. WehnTrust is open-source. Complete details of Ozone’s implementation is not available.
It was noted in February 2012 that ASLR on 32-bit Windows systems prior to Windows 8 can have its effectiveness reduced in low memory situations. Similar effect also had been achieved on Linux in the same research. The test code caused the Mac OS X 10.7.3 system to kernel panic, so it was left unclear about its ASLR behavior in this scenario.
The only way to reliably bypass DEP and ASLR is through an pointer leak. This is a situation where a value on the stack, at a reliable location, might be used to locate a usable function pointer or return-oriented programming gadget. Once this is done, it is sometimes possible to create a payload that reliably bypasses both protection mechanisms.
OllyDbg
OllyDbg (named after its author, Oleh Yuschuk) is an x86 debugger that emphasizes binary code analysis, which is useful when source code is not available. It traces registers, recognizes procedures, API calls, switches, tables, constants and strings, as well as locates routines from object files and libraries. It has a friendly interface, and its functionality can be extended by third-party plugins. Version 1.10 is the final 1.x release. Version 2.0 was released in June 2010, and OllyDbg has been rewritten from the ground up in this release. The software is free of cost, but the shareware license requires users to register with the author. Also the current version of OllyDbg cannot disassemble binaries compiled for 64-bit processors, though a 64-bit version of the debugger has been promised. OllyDbg 2.01 is a 32-bit assembler-level analyzing debugger with intuitive interface. It is especially useful if source code is not available.
OllyDbg is often used for reverse engineering of programs. It is often used by crackers to crack software made by other developers. For cracking and reverse engineering, it is often the primary tool because of its ease of use and availability; any 32-bit executable can be used by the debugger can be edited in bitcode/assembly in realtime. It is also useful for programmers to ensure that their program is running as intended, and for malware analysis purposes.
