隨著網路發展的演進，不正當存取系統資源的可能性也隨之提升，最有名的例子是1988年的莫里斯網路蟲。但是有些攻擊非但是存取系統資源，而且還惡意取得系統管理者的權限去進行破壞。過去的幾十年間，這樣類似的攻擊已經佔了大多數，而且一旦攻擊成功同網域的電腦也會陷入危險當中。於是，針對這類攻擊的防禦研究也隨之開始發展，這當中包含了各式各樣的研究方向 - 編譯器，組譯器，載入器，作業系統核心等等。簡單的說，這些研究方向都在安全和效率之間作不同的考量與分配，這份研究報告整理出這些研究方向彼此之間的關係並且提出了一個可以提高安全性卻不會失去效率的新方法(SegSafe)。
這新方法(SegSafe)利用英特爾x86系列中央處理器的保護模式去設定每個程序的堆疊區段成為唯讀。由於堆疊區段都是唯讀，任何程式裡的函式想要寫入堆疊區段都會引起例外處理程式(exception handler)而新方法(SegSafe)就是在這例外處理函式裡加入新的程式碼。新的程式碼包含兩個主要的目的 – 第一是紀錄寫入堆疊區段的函式並且判別同一個函式，第二是根據寫入的位址找尋合法可以寫入的邊界並加入函式的紀錄中。由於保護模式底下任何例外處理函式都會被賦予錯誤資訊，而這錯誤資訊包含了引發錯誤的程式碼位址和寫入的位址， 根據這些資訊可以用來達成第一個目的。另外由於傳統的程式呼叫，會在堆疊區段產生堆疊區塊，所以堆疊區段可以視為堆疊區塊的集合，若是知道開始區塊的位址就可以以此回推找尋任何一塊在堆疊區段的堆疊區塊，如果錯誤資訊裡的寫入的位址剛好在某塊堆疊區塊中，那麼該區塊的邊界及是合法可寫入的最後位址，根據這方法第二目的就可以被達成。在第一個目的中，相同的函式可以被重複辨識，而第二個目的把邊界的資訊在第一次紀錄函式時放入紀錄中，所以在重複辨識的過程中，可以把寫入的位址與邊界作比較已達成偵查的目的且不需再計算邊界第二次。由於新方法(SegSafe)借助x86硬體特性去偵測惡意函式的存在，相對於先前的防禦研究著重於定義惡意函式可能的架構，安全性明顯的提升且偵測效率並不會降低。同樣的，新方法(SegSafe)根據堆疊結構和堆疊區塊寫入函數的多寡把程式作分類，相同的安全性底下效率就會根據不同的程式而有所不同，相對於先前的防禦研究固定式的效能，新方法(SegSafe)提供了更大的彈性。

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.

[1] Donn Seeley, "A Tour of the Worm," 1989,
http://www.cerias.purdue.edu/coast/archive/data/categ29.html
[2]
M. Eichin, "With Microscope and Tweezers: An Analysis of the
Internet Virus of November 1988," Proceedings of the IEEE
Symposium on Research In Security and Privacy, 1989.
[3] M.
Eichin, "With Microscope and Tweezers: The Worm from MIT''s
Perspective," Communications of the ACM , June. 1989.
[4] Reed
Hastings and Bob Joyce, "Purify: Fast detection of memory leaks
and access errors," Proceedings of the Winter USENIX, 1992.
[5]
Nicolas Dubee, "lkm: Kernel hacking made easy," 1993,
http://www.w00w00.org/¯les/articles/lkmhack.txt
[6] Richard W M
Jones and Paul H J Kelly, "Bounds Checking for C," 1995,
http://www-ala.doc.ic.ac.uk/ phjk/BoundsChecking.html
[7] Silvio
Cesare, "System call redirection without modifying the system call
table," 1995, http://www.big.net.au/ silvio/stealth-syscall.txt
[8] Drew Dean, Edward W. Felten, and Dan S. Wallach, "Java
Security: From HotJava to Netscape and Beyond," IEEE Symposium on
Security and Privacy May 6-8, 1996, Oakland, California.
[9] Aleph
One, "Smashing The Stack For Fun And Profit," Phrack Magzine,
49(14), 1996, http://www.phrack.org
[10] Qian Zhang, "The
Synthetix MemGuard," 1997,
http://www.cse.ogi.edu/DISC/projects/synthetix/toolkit/MemGuard/
[11] Tom Shanley, "Protected Mode Software Architecture,"
MindShare, Inc, Feb. 1997.
[12] Alexandre
Snarskii, "Increasing overall security," 1997,
http://www.lexa.ru:8100/snar/libparanoia
[13] Nathan Smith, "Stack
smashing vulnerabilities in the UNIX operating system," 1997,
http://destroy.net/machines/security/nate-buRer.ps
[14] Michele
Crabb, Matt Bishop, Gene SpaRord, Steve Bellovin, Gene Schultz Rob
Kolstad, Marcus Ranum, Dorothy Denning, Dan Geer ,Peter Neumann,
Pe- ter Galvin, David Harley, and Jean Chouanard, "The SANS
Network Security Digest," 1997,
http://www.sans.org/newlook/digests/nsdigest.htm
[15] Jim Roskind,
"Panel: Security of Downloadable Executable Content," NDSS(Network
and Distributed System Security), February, 1997.
[16] Richard W M
Jones and Paul H J Kelly, "Backwards-compatible Bounds Checking
for arrays and pointers in C program, " Third International
Workshop on Automated Debugging, 1997,
http://www-ala.doc.ic.ac.uk/ phjk/BoundsChecking.html
[17] Herman
ten Brugge, "Bounds Checking C Compiler," 1998,
http://web.inter.NL.net/hcc/Haj.Ten.Brugge/
[18] Crispin Cowan and
Calton Pu, "Survivability From a Sow''s Ear:The Retrofit Security
Requirement," Proceedings of the 1998 Information Survivability
Work- shop , Orlando, FL, October 1998.
[19] Crispin Cowan, Calton
Pu, and Heather Hinton, "Death, Taxes, and Imperfect Software:
Surviving the Inevitable," Proceedings of the New Security
Paradigms Workshop , September 1998.
[20] Rafal Wojtczuk,
"Defeating Solar Designer''s Non-executable Stack Patch," 1998,
http://www.insecure.org/sploits/non-executable.stack.problems.html
[21] Linus Torvalds, "Posting to linux kernel mailing list," 1998,
http://www.lwn.net/980806/a/linus-noexec.html
[22] Anup K. Ghosh,
Tom O''Connor, and Gary McGraw, "An Automated Approach for
Identifying Potential Vulnerabilities in Software," Proceeding of
the IEEE Symposium on Security and Privacy, Oakland, CA, May 1998.
[23] Crispin Cowan, Calton Pu, David Maier, Heather Hinton, Peat
Bakke, Steve Beattie, Aaron Grier, Perry Wagle, and Qian Zhang,
"Automatic Detection and Prevention of Buffer Overflow Attacks,"
Proceedings of the 7th USENIX Security Conference, San Antonio,
TX, Jan. 1998.
[24] Crispin Cowan, Steve Beattie,
Ryan Finnin Day, Calton Pu, Perry Wagle, and ErikWalthinsen,
"Protecting Systems from Stack Smashing Attacks with Stack-
Guard," the Linux Expo, Raleigh, NC, May. 1999.
[25] Kurt Roeckx,
"Bounds Checking Overhead in SSH," Personal Communications,
October 1999.
[26] Frederic Raynal, Christophe Blaess, and
Christophe Grenier, "Avoiding security holes when developing an
application - Part 1 Part2 Part3," 1999,
http://www.linuxfocus.org/English/January2001/article182.shtml
[27] Crispin Cowan, Perry Wagle, Calton Pu, Steve Beattie, and
Jonathan Walpole, "BuRer Over°ows: Attacks and Defenses for the
Vulnerability of the Decade," the DARPA Information Survivability
Conference and Expo (DISCEX) (Co- sponsored by the IEEE Computer
Society), 2000.
[28] Arash Baratloo, Timothy Tsai, and Navjot
Singh, "Transparent Run-Time Defense Against Stack Smashing
Attacks," Proceedings of the USENIX Annual Technical Conference,
2000.
[29] OpenBSD, "OpenBSD Security,"
http://www.openbsd.org/security.html
[30] Tzi-cker Chiueh and
Fu-Hau Hsu, "RAD: A Compile-Time Solution to Buffer Overflow
Attacks," Distributed Computing Systems,2001. 21st International
Conference, 2001, pp.409-417
[31] Solar Designer, "Non-Executable
User Stack Patch," http://www.openwall.org/
[32] sd, and devik,
"Linux on-the-fly kernel patching without LKM," Phrack Magzine,
58(7), 2001, http://www.phrack.org
[33] Mike Frantzen and Mike
Shuey, "StackGhost: Hardware Facilitated Stack Pro- tection,"
Published in USENIX Security Symposium , 2001.
[34] Anon, "Linux
Security Audit Project," http://lsap.org
[35] Matt Conover,
"w00w00 on Heap Overflows," http://www.w00w00.org/articles.html
[36] Julian Hall and Simon Tantham, "Intel x86 Instruction
Reference,"
http://courses.ece.uiuc.edu/ece291/books/labmanual/inst-ref.html
[37] Mike Frantzen and Mike Shuey, "StackGhost: Hardware
Facilitated Stack Protection," USENIX Security Symposium 01, 2001.
[38] Hiroaki Etoh, "GCC extension for protecting
applications from stack-smashing attacks," 2003,
http://www.trl.ibm.com/projects/security/ssp/