安全漏洞的一些总结和心得

发表于:2010-7-09 11:11

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:fs_knownsec(baidu)    来源:51Testing软件测试网采编

分享:

  安全漏洞与BUG

  BUG是程序在开发和设计上,考虑的不够完善或实现存在错误,导致程序以设计和开发者未预期的方式或状态来执行的行为,安全漏洞是BUG的一种特殊形式。

  安全漏洞的定义应该是:能够让程序按非预期方式执行并且能使漏洞实施用户获得未被允许该用户执行或处理能力的BUG都是安全漏洞。

  安全漏洞是和具体的应用/系统定义的角色权限和定义相关的。

  一个例子是:一个拒绝服务漏洞只能影响实施漏洞的用户则只能说是BUG,但是能影响到其他用户对系统的使用,则是安全漏洞,因为突破了用户的能力和权限限制。(但是该漏洞如果要求实施漏洞的用户本身就具备影响其他用户对系统使用权限的情况下,如必须是受危害系统的系统管理员发起,也只能影响受危害系统的其他用户,则不能算是安全漏洞)

  另一个就是:还必须考虑应用环境下对角色的权限和能力的限制:IME(输入法)输入特殊按键导致IME宿主进程崩溃的BUG,在大多数情况下,只是一个BUG,但是对于象网吧,安装了系统交互操作保护的系统,则是安全漏洞。

  本质上,很多应用之下的不同角色划分,对系统而言是同一系统用户拥有相同的权限和能力,但是网吧的保护应用又区分了角色的能力,分成允许进入系统使用交互的用户角色和只许可运行网络游戏的用户角色。通过这个BUG能成功让保护应用关闭,突破了对原来角色能力的限制,而上升为安全漏洞。

  由应用在系统用户权限基础上再划分角色靠应用来进行管理,本身是不安全的,因为普通应用很难完整规划和设计用户的权限并加以检测,但是很多权限细节又难以靠系统本身来实现管理的,因此这样的应用又大规模存在。因此漏洞和BUG之间,很多时候是难以截然分开的。还必须考虑到之上的应用对角色权限和能力的限定。

  大多数安全漏洞都是BUG,都是属于设计者或开发者未预期的行为。但是一些因为设计就设计了不安全的功能的安全漏洞,则可能不是BUG。因为从未预期性来看,他们都是符合设计者和开发者预期的行为的,只是设计者和开发者根本就没考虑到这样的行为带来的潜在安全风险或者他们有意留下了后门。

  PS一下:任何系统都存在角色和用户权利的划分,一些是显性的,一个是隐性的。比如远程发起SYNFLOOD拒绝服务攻击的报文,相对与系统,则是一个匿名请求的未被认证的用户。该用户拥有的能力只应该限定在不影响其他用户的情况下发起请求。但是通过发起攻击,该用户具备了阻止其他合法用户使用系统的能力(权限),则成为安全问题。

  如何判断一个BUG是否是一个安全漏洞呢?

  其实也是遵循以上原则:判断是否能够提供突破限制能力,同时必须考虑起应用本身的对角色限制。

  一个简单的案例:一个只影响提交CSS的用户的CSS漏洞是否算安全漏洞一直存在争议,自己黑自己,如果从系统权限的角度来说,没有任何意义,所以只能算BUG,但是考虑到应用对角色的限定,则可能是安全漏洞。

  XCON上,会场有一个自动查询周围地图和餐饮的设备,启动后用自动的WEB界面盖住真实系统桌面以防止用户操作系统,WEB只提供简单的WEB查询,但是查询的时候没有过滤脚本,使用者可以很轻易的饶过WEB的界面限制打开其他的站点甚至调用系统的其他命令来执行,这个时候就成为安全漏洞了,虽然黑自助查询没什么太大的价值,但是很多自助终端甚至包括金融的都是按照这样的模式来实现的,所以按这一模式实现的应用,即使是自己黑自己的CSS的BUG,也会升级为安全漏洞。

  所以在分析一个BUG是否属安全漏洞,首先应该分析该漏洞影响的场景,然后划定攻击发起者的许可的能力范围(包括应用层的限定),然后看BUG实施时和实施后,攻击者是否具备了超过许可能力范围之外的能力,来确认一个BUG是否属于BUG还是一个安全漏洞,对于安全研究者来说,主要还是应该关注和研究安全漏洞而不是BUG。

  另一个我在BLUEHAT上讲的一个演示例子就是这样:ACCESS的MDB漏洞一直被认为由于ACCESS本身就是MS认为不安全的应用,如许可脚本执行,用户应该自己为MDB是否安全做判断,所以MS在2007之前对ACCESS的漏洞都不怎么做修补。但其实,即使认可MS的这种看法,但是数据库操作作为一种系统核心支持能力,在多种场景应用,完全存在一些应用场景是不由用户控制自主可以判断的场景,比如IIS如果打开了RDS功能,攻击者完全可以用MDB未修补的漏洞远程攻击IIS,所以在我的演示后,MS才对ACCESS的安全漏洞的策略做了些调整,把历年来积累的ACCESS漏洞做了修补。(这里的逻辑是:任何一个MDB拿来用ACCESS打开的场景下,用户必须确认其可信,然后再执行,默认就是许可MDB发起者拥有了你的权限,漏洞获得的权限也没超过你的权限范围,如果用户没确认可信就打开就和运行一个不受信任的程序后中招一样由用户自己负责,MS站点有专门的一个页面来列举了一些不安全应用文件如MDB不受可信保护,用户必须自己确认安全后才能打开,所以按照前面的安全漏洞划定规则,在这个场景下他不算漏洞只算BUG,如果要证明其是安全漏洞,必须证明一些场景可以突破对MDB发起者的限制来获得额外的能力)

  当然这对很多安全研究也是一种逆向的思维:去找一些大家都认为只是BUG的东西的没被大家考虑到的应用场景,是否存在利用的可能。你可能会找到很多有意思的东西。

《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号