dc.description.abstract | As the internet is growing, the opportunities for
improper attempts to access remote systems has potentially
increased. Several security attacks, such as the 1988 Internet
Worm, have become entrenched in Internet history. Some attacks
merely annoy or occupy system resources, but other attacks are
more insidious because that they seize root privileges and modify,
corrupt, or steal data. In recent years, attacks that exploit
buffer overflow bugs have accounted for approximately half of all
reported CERT advisories. Buffer overflow attack can inflict
upon almost arbitrary programs and becomes one of the most common
vulnerability that can seriously compromise the security of a
network attached computer system. To avoid this problem, plenty
of famous solutions are presented and each of them is developed
under the different allotment consideration between security and
efficiency. This thesis describes a new improved scheme - SegSafe
which can lift up security without losing efficiency by
incorporating the concept of two previous solutions - LibSafe and
MemGuard.
The reasons to select the concept of LibSafe consist in the
efficiency enhancement on StackGuard. More than just inspection
between stack frames like StackGuard does, LibSafe starts to
investigate ``only" when suspected function raises. But, the
preliminary definition of suspected function is un-reliable and
obstructs the construction of library. Therefore, SegSafe
advances to combine x86 hardware facility to secure malicious
function detection without pre-definition and eliminate the
special concern while library is constructed. Instead of setting
dynamic memory pages as read-only like MemGuard, SegSafe sets up
entire stack segment of user process as read-only while process is
started for the first time. And, the x86 protected mode software
architecture is used by SegSafe to set the attributes of stack
segment in each process. Because the stack segment is read-only,
any intent to write stack segment would trigger SegSafe’’s
exception handler and which will be notified where ``possible"
suspected function is (CS:EIP) by x86 hardware. After the address
of suspected function is located for sure, reverse engineering
will be performed to seek which kind of memory writing instruction
(``push" or ``mov" serious instructions) is at that address and
exile out false alarm (``push" serious instructions) to get the
``real" suspected function. Then, the identical information
(CS:EIP and SS:ESP etc) for each ``real" suspected function will
be collected and documented as an entry for comparison because
memory writing function would be compiled into one memory
writing instruction with successive writing address. In other
words, the sequential writing address will be treated as the same
variable by following procedures - comparing ``identical
information" in the entry, recording start writing address into
``start address" in the entry, and recording successive writing
address into ``end address" in the entry.
At the same time, the concept of LibSafe is performed to find the
zero-barrier which stands for the ``stack base address" which
points at the stack frame where the same variable exists. And,
the zero-barrier will be recorded in the same entry while the
first writing address of variable triggers the handler which
records it as an entry in the table. Later on, the successive
writing address of the same variable will be recognized (by
comparing identical information) and compared with the
zero-barrier in the record to achieve inspection on overflow
between stack frames - ``external stack overflow attack". Contrast
to precarious identification of suspected function in LibSafe
,SegSafe makes the identification of suspected function more
secure (from byte-code level) and the construction of library
would not be disturbed too. Meanwhile, unlike LibSafe which finds
out the zero-barrier every time suspected function starts, SegSafe
costs ``only" one searching time (searching zero-barrier) for each
variable. In conclusion, the main achievement of SegSafe is
followed by the original concept of classifying the buffer
overflow attack by ``when" the attack happens and ``where" it
attacks. Because the time attack begins will be notified by
hardware and analyzed by SegSafe’’s exception handler from
byte-code level, the detection of ``suspected & malicious"
function will be more secure than ever. Also, because where it
attacks relates with the distance of zero-barrier which equally
represents the number of stack frames been traced, the time
complexity of SegSafe will not be a fixed number but vary by the
stack structure and the quantity of writing functions in the
program. The other additional benefits came along with SegSafe
are working with any existing pre-compiled executable program
because SegSafe exists in the OS and no need to access the program
source code or change modern x86 hardware architecture because
SegSafe is based on protected mode ``software" mechanism. | en_US |