4 Experimentation and Observation
4.4 Overhead of Protection
由第三章所述的保護機制可知，我們在 vulnerable function 中檢查不合法的寫入，
由於進入 vulnerable function 的機會，與在 vulnerable function 中寫入 CS data 所在的分頁 中的機會，會依照不同的程式漏洞而有所不同，而產生不同的額外負載比例，因此我們 在接下來的實驗中，分別測量 Apache、Sendmail、Thttpd、Telnetd、Wu-ftpd，以觀察我 們的保護機制所產生的效能差異。這一節的實驗是測量在偵測到攻擊與 identification 後 的各種 service 效能表現，也就是在已經獲得攻擊者欲改寫之 CS data 以及 vulnerable function 等資訊之後，我們將各個 service 中欲保護的函數之起始與結束指令取代成 breakpoint，之後即開始我們的測量，利用 benchmark 或測試程式對各種 service 進行 request，當 request 造成 service 進入 vulnerable function 時，會執行 breakpoint 進入我們 的 handler 以及利用已取得的攻擊資訊進行保護處理。可知道這時候的情況變會與原本 的 service 產生效能差異，接下來將介紹各種不同的服務軟體與攻擊所產生之實驗結果。
4.4.1 Apache
此實驗的Apache版本為 1.3.32，此版本的Apache在mod_include module中有一個漏 洞[30]，此module會先運算處理過被request的一些檔案後才送給client，造成攻擊者能夠 利用buffer overflow改寫return address。在此實驗中，我們將Apache中已辨識出的 vulnerable function之啟始指令與結束指令取代為breakpoint之後，利用Webstone
benchmark，當benchmark進行request時，若導致service執行到vulnerable function且改寫 到已辨識出的CS data所在的分頁時，就會進入protection handler，而此漏洞只有在客戶 端請求server-side includes file (.shtml檔案)時，才會進入vulnerable function。依照不同的 server-side includes file比例(在全部請求檔案中所佔的比例)，利用Webstone benchmark測 得server throughput。如Figure 10 所示，當沒有任何server-side includes file(0% .shtml)時，
由於apache並沒有執行到vulnerable function，所以此時是沒有overhead的，而隨著 server-side includes file的比例增高，overhead也會逐漸增高，當所有請求檔案皆為 server-side includes file時會有最高的overhead(大約為 8%左右)，由此可知，儘管在所有 檔案都請求都會進入vulnerable function，效能降低的比例也仍然能夠接受。因此，我們 的保護機制能夠實際被使用。
Normal Our work Overhead
0
100% .shtml 75% .shtml 50% .shtml 25% .shtml 0% .shtml Probabilities of requesting .shtml files
Server throughput (Mbits/sec)
0
Figure 10: Performance overhead on Apache of protection
Figure 11 為我們在 server 上利用 top 命令測得上述 Apache 實驗的 CPU 使用率，由
0 5 10 15 20
100% .shtml 75% .shtml 50% .shtml 25% .shtml 0% .shtml Probabilities of requesting server-side include files
CPU utilization (%)
0
CPU utilization increment (%) Normal Our work Increment
Figure 11: CPU utilization on Apache of protection
4.4.2 Sendmail
此實驗的Sendmail版本為 8.12.9，此版本的Sendmail在prescan( )時由於沒有檢查邊 界，導致在heap data發生buffer overflow [33]。prescan( )是用為分析處理名稱字串並回傳 一組token。在辨識出攻擊資訊之後，我們利用Postal benchmark對sendmail進行request，
當進入vulnerable function時，就會因為執行了我們取代成breakpoint而進入保護處理，利 用Postal測量出此版本Sendmail每分鐘接收的message數目與資料量。Figure 12 為我們的 保護機制相較於正常沒有保護機制下的overhead，與我們在server上利用top命令測得執 行Postal benchmark時的server端CPU使用量之測量結果。可發現message傳送量的 overhead大約在 3%以內，而資料傳輸量的overhead約為 2%，而CPU使用率的增加量也 不到 1%，因此能夠得知，在此例子中，我們的保護機制造成的效能降低，是可以被接 受而能夠被實際使用的。
Figure 12: Performance overhead & CPU utilization on Sendmail of protection 0
Messages Data(K) NormalOur work
0
CPU utilization (%)
4.4.3 Thttpd
在Thttpd version 2.22 中，當客戶端請求一個網頁伺服器中沒有的檔案(non-found file)，則Thttpd會進入defang( )函數以簡化客戶端輸入的字串，而此函數中的一塊buffer 在被寫入時，由於沒有做好邊界檢查，因此能夠被惡意攻擊者輸入特定的字串而攻擊 local data[34]。在辨識出攻擊資訊以及利用breakpoint取代vulnerable function的起始與結 束指令之後，為了能夠測量抓取網頁伺服器中沒有的檔案時，server的回應時間，我們 利用自己的測試程式，從第一個連線建立之前開始計時，經過中間的request與接收server 回應的資料至連線結束，重複 10000 次後結束計時，以測得 10000 次request之時間。當 抓取non-found file時，thttpd仍會回傳一個檔案，以告知client端使用者其請求的檔案在 server中是無法找到的，因此我們仍可測得請求non-found file所需…的時間。如Figure 13，我們依照不同non-found file佔全部抓取檔案的比例測得抓取 10000 次non-found file 或一個 5K大小之檔案總共需要的時間，由圖中可知，在所有檔案皆為non-found file時，
我們的保護機制與原本的Thttpd皆需約六秒的時間且overhead約為 4%左右。隨著 non-found file所佔的比例下降，而overhead也逐漸降低。
0
Probabilities of requesting non-found files Time costnig of handling 10000 files (seconds)
0
Our work Non-Reloc Overhead
Figure 13: Performance on Thttpd of protection
4.4.4 Wu-ftpd
Wu-ftpd 2.5.0 讓攻擊者有機會在更換工作目錄(Chang Working Directory)時輸入過 長的字串而改寫global data，讓攻擊者能夠控制程式至指定的位址執行程式碼[35]。在辨 識出攻擊資訊之後，即vulnerable function的起始與結束指令取代成breakpoint之後，我們
利用dkftpbench benchmark測量抓取一個檔案所需的時間，為了能觀察出效能差異，我們 稍微修改dkftpbench，讓每次連線都先下 40 次CWD命令之後，才抓取一次檔案，而測 量的時間是從每次連線開始至檔案抓取結束，利用這樣的方式增加我們保護機制的負 載，以實際觀察出效能表現差異。如Figure 14，可以發現在抓取 2 bytes大小之檔案時，
會有最高的overhead，大約在 4%左右。隨著抓取之檔案越大，overhead則越來越小。這
2bytes 10K 1M 5M
File size Time of requesting a file (seconds)
0
Figure 14: Performance on Wu-ftpd of protection
4.4.5 Telnetd
Telnetd version 0.17 中的 netoprintf( )沒有做好 maxsize 邊界檢查導致惡意攻擊者能 利用 buffer overflow 攻擊的方式改寫 global data [43]，netoprintf( )會把輸入的字串參數傳 送至網路上。我們利用自己的測試程式，從第一次對 server 進行 telnet 開始計時至完成 第 1000 次的 telnet 連線。測量我們在辨識出攻擊資後啟動保護機制的 server，與原本無 保護機制的 server 之連線時間差異。Figure 15 為利用 telnetd 測量之實驗數據，此數據為 原本 Telnetd 與我們的保護機制在 telnet 1000 次所花費的時間，大約都在 50 秒左右，
overhead 不到 1%，因此我們能夠得知，在此情況下保護 global data 所造成的效能降低，
是能夠被接受而得以實際使用在 telnetd service 上的。
45
Time of 1000 telnet connection establishment (seconds)
noraml our work
Figure 15: Performance on telnetd of protection