|
WehnTrust, at its core, is an implementation of Address Space Layout Randomization
(ASLR) for Windows. While not a complete solution, ASLR does raise the bar for
exploit writers and in many cases makes exploitation impossible due to the
elimination of reliable return addresses that are accessible to a would-be attacker.
|
|
While WehnTrust is a major step forward for exploitation prevention on Windows,
it is not perfect. With that said, it is important to note that the fact that
it is imperfect does not mean that there is an inherent design flaw or that it's only
a matter of time before it's easily bypassed. Instead, it does mean that, given
the right set of circumstances for a given software vulnerability, it may be
possible for an attacker to exploit a software vulnerability even with WehnTrust
enabled. Though it may seem atypical, Wehnus believes that it is better to give
users the full story behind the product instead of hiding behind vague statements
that may or may not indicate that a user is protected. There are four conditions,
thus far identified, that may potentially be used to leverage a software vulnerability,
regardless of whether or not WehnTrust is installed on a machine: information leaks,
partial address overwrites, brute force attacks, and non-relocated executables.
Each of these conditions will be discussed in detail in the following paragraphs.
Information Leaks
An information leak is most easily thought of as a condition by which an application,
either intentionally or unintentionally, provides an attacker with information that
may facilitate the exploitation of a software vulnerability. For instance, a
specific class of software vulnerabilities, known as format string vulnerabilities,
can allow an attacker to read sequential values from the stack which can be used to gather
information about the offsets to certain values. Under conditions where it is possible
for an attacker to gain information about the layout of a process' address space remotely
without disturbing the process' execution path, it may be possible for an attacker to
exploit a software vulnerability regardless of whether or not WehnTrust is installed.
To better understand how information leaks are a problem, consider the following analogy.
A student is taking a college course and is studying for their final exam. As chance
would have it, the professor accidentally leaves their computer unlocked, giving the
student the chance to look at all of the questions that will be on the final exam. With
this knowledge, the student is able to study the specific topics that will be tested on
and is thus able to make an easy A on the final exam. In this analogy, the student
represents an attacker who is attempting to take advantage of an information leak which
is provided through the professor accidentally leaving their computer unlocked. The
student then took advantage of the information leak by studying
only the specific topics that were necessary to pass, or exploit, the final exam.
As it relates to WehnTrust, and any product that implements Address Space Layout
Randomization, an application that leaks information about its address space layout
to an attacker is at risk due to the fact that the information that was once unknown
to the attacker, namely the layout of the process' address space, becomes known. This
elimination of an unknown variable may make it possible for an attacker to exploit
a software vulnerability.
A specific example of a software vulnerability that may be exploitable regardless of
whether or not WehnTrust installed is the recently released
WINS Replication
vulnerability. Due to the fact that the replication protocol leaks memory addresses
that are relative to the WINS process, it may be possible for an attacker to construct
an exploit that takes advantage of the information leak to successfully exploit the
actual vulnerability.
Update: The commercial version of WehnTrust has support for detecting and
preventing information leaks that are achieved through certain format string routines, such
as printf. While it is not able to prevent all forms of information leaks, this
can at least be seen as an improvement to the problem.
Partial Address Overwrite
A partial address overwrite is a term used to describe the scenario where only part
of a memory address is overwritten during a buffer overflow. This condition is
most applicable to stack-based buffer overflows where only part of a return address
or a frame pointer is overwritten. The reason that partial address overwrites are
a concern with regard to products that use Address Space Layout Randomization is
that, depending on whether or not the architecture is little endian, it may be
possible to overwrite one or more of the least significant bytes of an address,
thus making it possible to refer to an absolute memory address that is relative
to the address being partially overwritten. Consider the following example:
A program that is vulnerable to a stack overflow is being exploited on a
machine that has Address Space Layout Randomization enabled. Due to the fact
that the attacker does not know of an absolute address that they can overwrite
the return address with to properly redirect execution into the buffer they're
overflowing, the attacker must instead figure out another attack route that
could be used to accomplish the same goal. In this example, the return address
on the stack is set to 0x1000428c. The attacker happens to know, through
their research of the vulnerable application, that an instruction exists at
0x100042ad that could be used to transfer execution into the buffer that
they control. Knowing this, the attacker could simply overwrite the least significant
byte of the return address with 0xad, thus changing the return address to
0x100042ad. When the function returns, execution is transferred to the modified
return address and eventually into the attacker's controlled buffer. The attacker
did not have to know the full address at which the instruction was located, but
rather only needed to know the relative location of the instruction.
While partial address overwrites are in most cases impossible and not commonly used
by attackers when implementing exploits, there are still some vulnerabilities that
may be exploitable through partial address overwrites.
Update: Wehnus, Inc. has identified a partial solution to this problem
and hopes to include support for it in a future version of the commercial product.
Brute Force Attacks
A brute force attack is a general term used to describe the process by which
a given outcome is achieved through trial and error. In relation to software
vulnerabilities, a brute force attack typically refers to the process by
which an exploit attempts to leverage a software vulnerability by trying
various addresses or offsets that are either not predictable or change
between one execution of an application to the next. Brute force attacks are
generally not possible against Windows based applications because if an exploit
is attempted against an unpatched machine that does not use the right addresses,
the target application will crash. With that said, some Windows applications, such
as certain services, will respawn after a given time interval, thus making it possible
to try various addresses over a given span of time.
Brute force attacks are only a concern if it is possible for an attacker to easily
and steathly determine a compatible address in a target process. Due to the fact
that WehnTrust randomizes the address space of each process, this guesswork
is made much harder and in some cases impossible depending on the specific
software vulnerability.
Update: The commercial version of WehnTrust supports detecting when brute
force attacks are occurring and has logic built in to attempt to stop the brute
force attack.
Non-relocated Executables
In some cases executable image files (typically only .EXE files) are compiled without
information that is needed in order to change the address that they reside at in memory.
When this information does not exist, the image file cannot be safely relocated and thus
will remain at a static address from one execution to the next. DLL files, by their
very nature, should always have relocatable information because they are designed to not
be tied to a specific address in memory in most cases. EXE files, however, are one of the
first regions of memory that are mapped into a process' address space when a process begins
executing. Due to this fact it is usually not a requirement that an executable image file
be relocatable in memory.
If an executable image file does not have relocatable information, WehnTrust will not be
able to relocate it and thus it may be possible, under the right circumstances, for an
attacker to take advantage of the known address region when exploiting a software
vulnerability. In the majority of cases it is not possible to use the executable's
address region when exploiting a software vulnerability due to a number of factors, such as
the region having invalid characters or not having an instruction that can be used
to redirect the execution path of the process.
Update: Wehnus, Inc. is still analyzing potential solutions to this problem and
has a few approaches on the table. We are still hoping to release support for this
in a future release.
|
|
|
