[TOOL] wkr - Heap Protection
From: SecuriTeam (support_at_securiteam.com)
Date: 12/03/03
- Previous message: SecuriTeam: "[NEWS] SNMP Trap Reveals WEP Key in Cisco Aironet Access Point"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
To: list@securiteam.com Date: 3 Dec 2003 15:50:20 +0200
The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
The SecuriTeam alerts list - Free, Accurate, Independent.
Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html
- - - - - - - - -
wkr - Heap Protection
------------------------------------------------------------------------
DETAILS
Anatomy of the Heap-based Overflow
The classic heap-based exploit relies upon a macro used in free memory
chunk list manipulations in glibc's heap management code. By overflowing a
chunk, an attacker can set the values of the fd and bk pointers of the
next chunk header in memory. When the unlink macro is subsequently called
on the overflown chunk header, a write to a memory location specified by
the attacker with a value also specified by the attacker can occur. If the
attacker is careful enough to supply the correct values to the chunk list
pointers, the attacker can modify a function return address, a GOT or PLT
entry, or an application-level pointer in order to subvert the control
flow of the process.
Other variants of this attack exist, including using the frontlink macro
or exploiting the size fields of memory chunk headers in conjunction with
fake chunk headers, but they operate on the same general principles.
Technique
The technique employed in our heap protection patch is an adaptation of
canary-based schemes used by various stack protection patches. This is
based off of the observation that by placing a canary word in front of the
data to be protected, one can determine whether the protected data has
been modified before the attacker has a chance to gain control of the
process. In the case of a buffer overflow, the canary word must
necessarily be modified if the protected data is modified. If the attacker
is able to jump over the canary, he is in general able to write to
arbitrary memory locations and thus already has the ability to subvert the
process' control flow, e.g. by directly attacking the process GOT or PLT.
An important detail to note is that the value of the canary word must be
difficult for the attacker to guess. Otherwise, the attacker could simply
overwrite the canary with the expected value and thus complete his attack
undetected. Some systems have opted to use a series of string-terminating
NULL bytes, derived from the observation that if the attacker must include
these in his overflow string, he cannot use the standard C library string
functions to overwrite the protected data. In our patch, we currently use
a random seed which is generated at process start and subsequently
protected from further writes using a call to mprotect(). This prevents
the attacker from setting the seed to a known value in some way, reducing
the canary to a guessable value.
For glibc, we had to modify the structure of a memory chunk in order to
implement our scheme. The original structure of a memory chunk in glibc
consisted of a previous size field, a size field, and optionally two
pointers, bk and fd. These pointers are only in use when the chunk has
been freed, as they reside in the user data section of the chunk as an
optimization. Otherwise, only the previous size and size fields are used.
The modified structure of a memory chunk has two fields prepended to the
original structure, a canary field called magic and a padding field used
to enforce the constraint that the size of a memory chunk header must be a
power of two.
The remainder of the technique consists of setting canaries for allocated
and freed blocks and inserting consistency checks into glibc's heap
management code at appropriate points. Consistency checks on the canary
are performed before each manipulation of a chunk's pointer fields; thus,
an attacker has no opportunity to corrupt memory. Canaries are set after
any operation which changes the size or pointer fields of the chunk.
An evaluation of the performance and detection capabilities of the current
implementation is
<http://www.cs.ucsb.edu/~wkr/projects/heap_protection/evaluation.html>
available, as well as the latest patches and binary
<http://www.cs.ucsb.edu/~wkr/projects/heap_protection/software.html>
packages.
ADDITIONAL INFORMATION
The tool is available from:
<http://www.cs.ucsb.edu/~wkr/projects/heap_protection/>
http://www.cs.ucsb.edu/~wkr/projects/heap_protection/.
The information has been provided by <mailto:wkr@cs.ucsb.edu> William
Robertson.
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.
- Previous message: SecuriTeam: "[NEWS] SNMP Trap Reveals WEP Key in Cisco Aironet Access Point"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
