A Guide to Kernel Exploitation Attacking the Core [Paperback]
465 pág.

A Guide to Kernel Exploitation Attacking the Core [Paperback]

DisciplinaLinux716 materiais1.853 seguidores
Pré-visualização50 páginas
attacks have
been increasingly popular in the past two decades. Consequently, all major user-
land software has been audited many times by many different hackers and security
researchers around the world. Obviously, software evolves, and it would be silly
10 CHAPTER 1 From User-Land to Kernel-Land Attacks
to assume that this evolution does not bring new bugs. However, finding new
vulnerabilities is not as prolific a task as it was 10 years ago.
We focused our attention on software approaches to prevent exploitation, but some degree
of protection can be achieved at the hardware level as well. For example, the x86-64
architecture (the 64-bit evolution of the x86 architecture) provides an NXB bit for physical
pages. Modern kernels may take advantage of this bit to mark areas of the address space
as nonexecutable, thereby reducing the number of places where an attacker can store
shellcode. We will go into more detail about this (and see how to bypass this protection
scheme) in Chapter 3.
Kernel-Land Exploits versus User-Land Exploits
We described the kernel as the entity where many security countermeasures
against exploitation are implemented. With the increasing diffusion of security
patches and the contemporary reduction of user-land vulnerabilities, it should
come as no surprise that the attention of exploit writers has shifted toward the
core of the operating system. However, writing a kernel-land exploit presents a
number of extra challenges when compared to a user-land exploit:
\u2022 The kernel is the only piece of software that is mandatory for the system. As
long as your kernel runs correctly, there is no unrecoverable situation. This is
why user-land brute forcing, for example, is a viable option: the only real
concern you face when you repeatedly crash your victim application is the noise
you might generate in the logs. When it comes to the kernel, this assumption is
no longer true: an error at the kernel level leaves the system in an inconsistent
state, and a manual reboot is usually required to restore the machine to its
proper functioning. If the error occurs inside one of the sensible areas of the
kernel, the operating system will just shut down, a condition known as panic.
Some operating systems, such as Solaris, also dump, if possible, the information
regarding the panic into a crash dump file for post-mortem analysis.
\u2022 The kernel is protected from user land via both software and hardware.
Gathering information about the kernel is a much more complicated job. At
the same time, the number of variables that are no longer under the attacker\u2019s
control increases exponentially. For example, consider the memory allocator.
In a user-land exploit, the allocator is inside the process, usually linked
through a shared system library. Your target is its only consumer and its only
\u201caffecter.\u201d On the other side, all the processes on the system may affect the
behavior and the status of a kernel memory allocator.
B The NX (or nonexecutable) bit can also be enabled on 32-bit x86 machines that support Physical
Address Extension (PAE). We will discuss this in more detail in Chapter 3.
Why Doesn\u2019t My User-Land Exploit Work Anymore? 11
\u2022 The kernel is a large and complex system. The size of the kernel is substantive,
perhaps on the order of millions of lines of source code. The kernel has to
manage all the hardware on the computer and most of the lower-level software
abstractions (virtual memory, file systems, IPC facilities, etc.). This translates
into a number of hierarchical, interconnected subsystems that the attacker may
have to deeply understand to successfully trigger and exploit a specific
vulnerability. This characteristic can also become an advantage for the exploit
developer, as a complex system is also less likely to be bug-free.
The kernel also presents some advantages compared to its user-land counterpart.
Since the kernel is the most privileged code running on a system (not considering
virtualization solutions; see the following note), it is also the most complicated to
protect. There is no other entity to rely on for protection, except the hardware.
At the time of this writing, virtualization systems are becoming increasingly popular, and it
will not be long before we see virtualization-based kernel protections. The performance
penalty discussion also applies to this kind of protection. Virtualization systems must not
greatly affect the protected kernel if they want to be widely adopted.
Moreover, it is interesting to note that one of the drawbacks of some of the
protections we described is that they introduce a performance penalty. Although this
penalty may be negligible on some user-land applications, it has a much higher
impact if it is applied to the kernel (and, consequently, to the whole system). Perfor-
mance is a key point for customers, and it is not uncommon for them to choose to
sacrifice security if it means they will not incur a decrease in performance. Table 1.1
summarizes the key differences between user-land exploits and kernel-land exploits.
Table 1.1 Differences between user-land and kernel-land exploits
Attempting to\u2026 User-land exploits Kernel-land exploits
Brute-force the
This leads to multiple crashes
of the application that can be
restarted (or will be restarted
automatically; for example, via
inetd in Linux).
This leads to an in-
consistent state of the
machine and, generally,
to a panic condition or a
Influence the target The attacker has much more
control (especially locally) over
the victim application (e.g.,
the attacker can set the
environment it will run in).
The application is the only
consumer of the library
subsystem that uses it (e.g.,
the memory allocator).
The attacker races with all
the other applications in
an attempt to \u201cinfluence\u201d
the kernel. All the
applications are
consumers of the
kernel subsystems.
12 CHAPTER 1 From User-Land to Kernel-Land Attacks
The number of \u201ctricks\u201d you can perform at the kernel level is virtually
unlimited. This is another advantage of kernel complexity. As you will discover
throughout the rest of this book, it is more difficult to categorize kernel-land
vulnerabilities than user-land vulnerabilities. Although you can certainly track
down some common exploitation vectors (and we will!), every kernel vulnerability
is a story unto itself.
Sit down and relax. The journey has just begun.
In the preceding section, we outlined the differences between user-land and
kernel-land exploitation; from this point on we will focus only on the kernel. In
this section, we will go slightly deeper into some theoretical concepts that will be
extremely useful to understand; later we will discuss kernel vulnerabilities and
attacks. Since this is not a book on operating systems, we decided to introduce
the exploitation concepts before this section in the hopes that the exploitation-
relevant details will more clearly stand out. Notwithstanding this, the more you
know about the underlying operating system, the better you will be able to target
it. Studying an operating system is not only fascinating, but also remunerative
when it comes to attacking it (for more on operating system concepts, see the
\u201cRelated Reading\u201d section at the end of this chapter).
User-Land Processes and the Scheduler
One of the characteristics that we take for granted in an operating system is the
ability to run multiple processes concurrently. Obviously, unless the system has
more than one CPU, only one process can be active and running at any given
time. By assigning to each process a time frame to spend on the CPU and by
quickly switching it from process to process, the kernel gives the end-user the
Table 1.1 Differences between user-land and kernel-land exploits (Continued)
Attempting to\u2026 User-land exploits