解决方法
$SAFE级别确实有助于您抵御系统级漏洞.如果攻击者能够将Ruby代码写入/ tmp中的文件,那么如果$SAFE> = 2,那么他们就不能欺骗程序加载该代码.
这当然不包括Ruby本身的任何漏洞.这些更严重,可以完全绕过$SAFE.
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3657
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3655
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3694
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2337
或者简单的旧缓冲区溢出,Ruby解释器本身的整数溢出等与$SAFE无关.
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-2489
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-4124
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2726
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2376
Rails是否启用$SAFE是否启用了历史漏洞.这是由于用户输入存储在Rails应用程序中,恶意数据可以在以后弹出来重现.
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-4214
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3009
除Rails和MRI之外的Ruby应用程序中的漏洞报告难以实现.
$SAFE的另一个大问题是没有真正的列表(我知道),概述了什么$SAFE做和不保护.关于唯一可以做的事情是在eval.c搜索ruby_safe_level(这是一个较老的eval.c从1.8.4).评论提供了这个描述,但它很模糊.
/* safe-level: 0 - strings from streams/environment/ARGV are tainted (default) 1 - no dangerous operation by tainted value 2 - process/file operations prohibited 3 - all generated objects are tainted 4 - no global (non-tainted) variable modification/no direct output */
我想我想说的是$SAFE是关于系统的安全性.它做得很好,但是没有真正的方式来确切地知道是什么,也没有被保护.它不应该是你唯一的防线,它更多的是一个安全网,所以没有任何通过“不安全的行动”.另一方面,它与应用程序安全性无关,并且不会保存您的数据或用户不被泄露.此外,MRI还有一个漏洞的历史,绕过了$SAFE.