Beyond the Void
BYVoid
Vakuum開發筆記02 核心與安全問題
本文正體字版由OpenCC轉換

3.judger核心設計

評測系統最重要部分就是評測核心了(judger)。核心judger負責了編譯、執行、檢查三大部分,也就是評測系統的靈魂所在,因此judger設計的好壞,直接影響到整個評測系統的整體水準。judger的設計要考慮到幾個方面,首先是對安全性要求很高。別忘了,這是一個在線評測系統,任何人都可以提交任何代碼,並在服務器上執行,這意味着給駭客們提供了方便之門。駭客們(注意,不是黑客)總是希望得到一個Shell,並在上面執行想要的命令。而評測系統直接允許了源碼的提交,如果我是駭客的話簡直樂壞了。當然,只有傻瓜纔會對用戶提交的代碼直接編譯、運行,就像編譯自己的程序一樣,限制是必不可少的。

不當的方法

一個愚蠢的方案是直接對代碼進行掃描,然後過濾掉某些字符串,如"system”。當然這個過濾列表可能長得匪夷所思,就像某牆,然而繞過它卻是很容易的,例如以下代碼:

#include <stdlib.h>
#define dosomething sys##tem
int main()
{
	dosomething("shutdown");
	return 0;
}

怎麼辦呢?有人會繼續想到,我可以用g++的-E命令,將預處理以後的代碼輸入到一個文件中,然後再檢查關鍵字。這樣的話上面的方法就不行了,不過更厲害的駭客還有辦法。什麼辦法呢?直接按地址調用函數,代碼如下:

#include <stdlib.h>
int main()
{
	int (*func)(char *);
	func = (int (*)(char*))134513676;
	func("ls");
	return 0;
}

上述代碼中的數值就是 system函數的絕對地址,在不同的環境中不一樣,不過獲取這個數值並不困難的。由此可見,依靠過濾源代碼的方式幾乎是行不通的安全性解決方案。如果不依賴檢查源代碼,就要監控程序的“行爲”,這就需要比較複雜的調試器技術了。在Linux下,有一個ptrace函數,可以在程序運行時監測程序的行爲,捕獲接收到的信號。

解決方案

vakuum的執行器executor,就是用的ptrace的原理。主程序爲兩個進程,子進程用來執行用戶程序,父進程用來監視子進程。子進程每進行系統調用的時候,運行就被中斷,由父進程檢查子進程的行爲是否合法,如果不合法就殺掉子進程。對於open調用,還要檢查用戶打開的文件是否被允許。有了這個程序,監控程序的用戶時間和內存也就不難了,用戶時間的監測需要在每個系統調用後檢查,對於內存,在任何一個與內存分配相關的系統調用後檢查一下/proc/{pid}/statm即可。

如此還有一個問題容易被忽略,就是如果用戶程序中長時間不進行系統調用,只是在做一些運算的時候,如何讓程序暫停下來判斷是否超時呢?設置CPU_Limit爲時間限制顯然是不行的,因爲在監控下的用戶程序可能會運行時間更久。不知道大家在用Cena的時候是否發現過一個現象,例如某個程序本來運行0.8秒,設爲1秒時限以後顯示超時,設爲2秒時間反而顯示成了0.8秒。這是怎麼回事呢?很可能就是設定了不合適的CPU_Limit。穩妥的方法是設置爲時間限制的若干倍,但是到底是幾倍不好估計,而且很多時候還會浪費時間。思考問題的根源還在於長時間沒有被暫停,我的解決方法是給父進程設置一個alarm,每秒向子進程發送一個信號,設置子進程接收到信號以後也會暫停,並檢查時間是否超時。這樣的話,超時的程序最多會在不超過時限1秒的情況下被終止。

在這種嚴密的監控下,很難找到突破的方法,至少我至今還沒有想到如何攻破executor的監控。其代價就是降低執行效率了,不過由於我監視的是用戶時間,用戶程序不會被誤判超時,儘管感覺實際執行時間多了不少。如果你有什麼攻破監控想法,歡迎與我聯繫做安全性測試。

潛在的缺陷

雖然我並不瞭解,但是我還是擔心,如果用戶程序中有彙編代碼嵌入,是否可以獲得底層的權限。如果真的可以,我還沒有想到應對的方法。


上次修改時間 2017-02-03

相關日誌