The lack of reliable binary exploits against Cisco IOS is also caused by the architecture of the target software. IOS is a monolithic binary running directly on the hardware of the respective router platform. While it features the look and feel of a head-less operating system, IOS is better compared to a multithreaded UNIX program.
IOS uses a shared flat memory architecture, leveraging the CPUs address translation functionality only to the point where a global memory map comparable to any UNIX ELF binary is created. IOS processes are little more than threads. Every process has its own CPU context and a block of memory as stack, but no further separation from other processes is enforced or enforceable. All processes on IOS share the same heap, a large doubly linked list of memory blocks, referenced by a couple of smaller linked lists for free block tracking. Depending on the router platform, there are additional memory regions that are all accessible from every piece of code running on the machine.
IOS uses a run-to-completion scheduling for its processes. All processes that receive execution must return to the scheduler in due time, in order to allow the execution of other processes. In case a process fails to return to the scheduler, a watchdog, supported by CPU hardware, is triggered and causes a so-called Software Forced Crash, which reboots the router.
Cisco IOS routers generally run on PowerPC 32 Bit or MIPS 32 or 64 Bit CPUs. Both CPU families support privilege separation for implementing kernel vs. user land execution. None of these features have been observed to be used in IOS so far. Any execution is performed on the highest privilege level the CPU supports, commonly referred to as supervisor level.
As a consequence of the architecture discussed above, the default behavior in case of a CPU exception or software detected but unrecoverable data structure consistency problem is to reboot the entire device. The architecture of IOS does not allow for any type of partial restart, since a misbehaving process could have already written into any writable memory area without the CPU noticing. Therefore, the only safe action is to reboot the entire system.
This behavior increases the difficulties for reliable exploitation of memory corruption vulnerabilities.
On common operating system platforms, primarily the Windows platform, using CPU exception propagation as a way of gaining code execution is a well established practice. On Cisco IOS however, every CPU exception will cause the machine to reboot. This might appear as acceptable for an attacker, but given that network infrastructure of any measurable importance is monitored for crashes and reboots of its components 24 by 7, it raises the bar for reliable exploitation.
The same problem also concerns any shellcode that would be executed once control over the instruction flow is obtained. Not only should the shellcode not trigger any CPU exception during its execution, it must also clean up and attempt to return execution to the exploited IOS process in order to allow normal processing to continue.
Finally, the allocation of process stacks on the common heap results in another challenge for exploitation. Stack based buffer overflows are the most simple and versatile memory corruption vulnerabilities, and IOS is not any different in that respect. Unfortunately, the stacks allocated by default to an IOS process are relatively small (6000 bytes) and the call graph of functions within the code is relatively short, so that buffers that could overflow are often close to the upper bound of the stack and hence the heap block. Overflowing the buffer with too much data will often cause overwriting of the next heap block's header. Once the heap header is destroyed, any allocation or deallocation of memory by any process on IOS will trigger a partial heap integrity check and cause the router to reboot when the corrupted heap header is spotted.
Additionally, IOS features a process called CheckHeaps, which will periodically (every 30 seconds) traverse the entire heap linked list and verify its integrity, also causing a reboot if any inconsistency is found.
Given that both CPU families in Cisco equipment employ fixed size 32 Bit instructions, a stack based buffer overflow is often hard to exploit within the bounds of available space up to the header of the following heap block.
0 comments:
Post a Comment