Beyond the Void
BYVoid
Vakuum开发笔记02 核心与安全问题

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

相关日志