| 摘要: | 隨著網路發展的演進，不正當存取系統資源的可能性也隨之提升，最有名的例子是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. |
