Perl脚本安全问题研究.pdfVIP

适合读者：编程爱好者、入侵爱好者 前置知识：Perl Perl 脚本安全问题研究 文/ Jordan Dimov 译/ 欧阳汉斌刚果果 程序语言正常情况下并不构成安全风险，风险是伴随着程序开发者而产生的。几乎每 一种语言都有这样那样的瑕疵，而这些瑕疵往往导致不少安全性不足的软件出现。但是整个 软件的安全性在很大程度上还是取决于作者的知识、对程序的理解以及安全意识。在安全方 面，Perl 有它自己的让人意料不到的特性，可大多数Perl 程序员却没有意识到它的存在。 下面，我们将从Perl 脚本的广泛特性及其误用问题着眼，看看这些不当的使用将会带 来何种的系统安全隐患，包括那些缺陷程序的广大用户正在使用的系统。同时，我们将会介 绍如何利用这些缺陷以及如何避免和修补这些漏洞。 基本的用户输入漏洞 Perl 脚本安全问题之一便是对用户的输入过滤不严（未经验证的用户input ）。很多时候， 你的程序会直接或者间接地接受一些来自未被信任的用户的输入，在这个问题上，程序员更 应该谨慎。例如，你正在用Perl 脚本编写一个CGI 程序，那你就应该要考虑到会有恶意的 用户给你的CGI 程序发送伪造的输入。 如果用户输入未经过验证便予以信任和使用，那么输入会导致该程序出现各种各样的 错误。最明显的一点就是程序执行的时候才知道我们执行的是别的用户提供的程序，而这种 程序没有经过任何检查和验证。 system()和exec()函数线 Perl 以复合语言著称，实际表现为能够很好地调用其他程序来为它协同工作，通过它 们的输出来协调运行情况，通过一种特别的方式把它们作为另一种形式的输入，传递给别的 防 程序，从而确保每个环节能够顺利运行。正如Perl 所告诉我们的，实现的方法不止一个。 执行外部程序或者执行一个系统命令我们只需要调用exec()函数便可。当Perl 遇到exec() 客 表达式的时候，便去寻找函数调用的参数，然后创建一个新的过程来执行指定的命令。Perl 不会把控制权交还给原先调用exec()函数的程序，而是直接进入函数的过程。 另外还有一个类似的函数是system()函数。system()和exe()过程十分相似，它们之间唯 黑 一的区别就是，perl 首先从初处理过程中分离出一个子程序来。这个子程序就是被送入系统 的参数，然后初处理等待直至子程序运行，再执行剩余的其他程序。下面我们来进一步讨论 system()函数的调用，但绝大部分的结论同样可以应用到exe()函数中。 被输入到系统的参数是一个列表形式，列表的第一项是被调用执行的程序名称，而剩 下的几项将作为参数被传递给该程序。尽管如此，如果只有一个参数的话，system()会异常 运行。在这种情况下，Perl 会扫描这个参数是否包含Shell 元字符，如果有的话，它会把这 些字符通过Shell 来解释。因此Perl 便产生了大量的内部命令来完成工作，否则Perl 将拆分 这些字符并调用更有效的C 程序库，但是这些库也不能很好地识别这些内部命令字符。 现在假设我们有一个CGI 表单需要用户名来列出一些文件 （包含用户的统计数据表）， 我们就可以通过system()来调用CAT 来实现我们的目的，代码如下： system (cat /usr/stats/$username) 而用户名$username 则来自下面这个表单项里： $username = param (username); 用户填写表单用户名，比如 jdimov ，然后提交它。Perl 却找不到任何元字符在 “cat /usr/stats/jdimov ”的字符串中，所以Perl 就调用 execvp()来运行“cat ”，再返回到我们的脚 本程序里来。这段脚本看上去没什么，其实是可以被别有用心的攻击者利用的。问题在于攻 击者可以在表单里面使用特殊字符来实现任意Shell 命令的执行。我们假设攻击者在用户名 的地方输入如下字符串：“jdimov; cat /etc/passwd ”字符串，Perl 把分号作为元字符发送到内 部命令Shell 中，像下面这样： cat /usr/stats/jdimov; cat /etc/passwd 入侵者将同