|
Exploitation
After an issue has been identified through the use of a fuzzer or through
manual analysis, it's necessary to begin the process of determining a way to
reliably gain control of the instruction pointer. In the case of stack-based
buffer overflows on Windows, this process is often as simple as determining
the offset to the return address and then overwriting it with an address of an
instruction that jumps back into the stack. That's the best case scenario,
though, and there are often other hurdles that one may have to overcome
regardless of whether or not the vulnerability exists in a device driver or in
a user-mode program. These hurdles and other factors are what tend to make
the process of getting reliable control of the instruction pointer one of the
most challenging steps in exploit development. Rather than exhaustively
describing all of the problems one could run into, the authors will instead
provide illustrations in the form of real world examples included in chapter
5.
Assuming reliable control of the instruction pointer can be gained, the
development of an exploit typically transitions into its final stage:
arbitrary code execution. In user-mode, this stage has been completely
automated for most exploit developers. It's become common practice to simply
use Metasploit's user-mode payload generator. Kernel-mode payloads, on the
other hand, have not seen an integrated solution for producing reliable
payloads that can be dropped into any exploit. That's certainly not to say
that there hasn't been previous work dealing with kernel-mode payloads, as
there definitely has been[2,1], but their form up to now has
been one that is not particularly easy to adopt. This lack of easy to use
kernel-mode payloads can be seen as one of the major reasons why there has not
been a large number of public, reliable kernel-mode exploits.
Since one of the goals of this paper is to illustrate how kernel-mode exploits
can be written just as easily as user-mode exploits, the authors determined
that it was necessary to incorporate the existing set of kernel-mode payload
ideas into the 3.0 version of the Metasploit framework where they could be
used freely with any future kernel-mode exploits. While this final
integration was certainly the end-goal, there were a number of important steps
that had to be taken before the integration could occur. The following
sections will attempt to provide this background. In section
4.1, details regarding the payload architecture that the authors
selected is described in detail. This section also includes a description of
the interface that has been exposed in the 3.0 version of the Metasploit
Framework for developers who wish to implement kernel-mode exploits.
Subsections
|