主题:一篇讲memory overflow导致被攻击的文章 -- yueyu
那能不能升级gcc编译器哪,让编译器在碰到这些函数的时候先预处理一下,这样只要从新编译,连接一下就可以了,这样一般程序员的习惯也不用调整了.安全专家们只要把发现的问题定期发布,更新一下编译器就行了.
以此为生的“黑客”没有“义务”向开源项目报告。
LINUX的管理员“水平高”能“发现”问题不意味着“发现”问题的关键。
发现的。
假如一个程序员有编写缓冲区溢出利用程序的能力,那他的水平已经是很不一般了。从市场的角度考虑,他不可能简单地去卖马赚钱。而一个程序员真的像你所说通过阅读源代码就可以发现软件的漏洞(到目前为止 Unix 系统中所有的程序都已经经过了几十年的检验),他基本上没有任何动机去隐藏他的发现,而去赚他根本不需要的钱。
从现在看到的景象,大多数贩卖、制作所谓的木马、病毒、 rootkit 之类的人渣不过是一些二道贩子,利用的都是些已知的漏洞而已。比起发现漏洞来还有很长的距离。
这里引出了另一个问题,那就是人们更关心的其实是如何利用已知的漏洞,而不是如何去发现漏洞。换句话说,系统是否被入侵其实源代码什么的毫无关系。更重要的是系统的提供商有没有尽到其相应的责任(例如做好文档工作、及时发布补丁、敦促用户升级系统)。微软在这上面是很失败的。
很难
编译器在编译期得到的信息很有限,库函数和调用库函数的代码可能不是同时编译的,即使是同时编译的,编译器也没有机制在编译两个文件的时候通讯。无法阻止所有的溢出可能。
c语言是很注重灵活和高效的,所以才有这种隐患吧,如果都堵严了,恐怕就变成另一种语言了。
其他某一些语言确实比c安全。
唯一能做的,就是碰到类似不安全函数调用的时候,给个warning,让程序员注意了。
倒不是说代码多么优秀,但是经过十几二十几年的公开测试和验证,其可靠性和安全性,还是值得信赖的。起码从一般意义上来说,比Windows的代码值得信赖,因为谁也不知道微软为这些代码做过多少的测试和分析,经过多少时间的验证。虽然微软一定会为此拍胸脯的,但是又有多少人真的完全相信他的保证呢?
一台计算机就可以开工,基本没有无聊成本。与之相比其他IT也怎么也得有个测试仪表,出个产品也得买材料,投PCB板
不是我虚构的,具体的用处,我也是想了一下才明白的。
strcpy
参数是char*
,原来是靠\0来判断结束的,而程序员也习惯了如此。编译器也不像strncpy一样有长度信息来判断copy多少个字节,所以也没办法做检测。一个可能的方案是再套一层VM,重新定义char*,让他默认编译进去一个length。这就是Java作的事情。
但是问题又来了,如果这个VM有安全漏洞呢?因为VM的实现,也只能是C。
当然,可以最底层的OS里面,char*就编译一个length进去,但连kernel都要重写了,工作量巨大。
我们教的时候都没有教国32位机的汇编,也就是说eax只存在于我的想象中(和老师开的课后读物---课后毒物的代名词)。。。
工作了也没用汇编干活,倒是我们班几个女生现在成了汇编高手了,因为她们不会用c。。。
不能说iPhone是这么被破解的。
这篇文章是很经典的return to libc 攻击。其实严格意义上说他不是一种新的BufferOverflow,而是将如何exploit BO。
Rafal是第一个提出这个思路的人,他因此在Security界享有广泛的声誉。类似的,他还发现了在MacOS下如何绕过NX保护的方法。
此公沉默寡言,桥牌水平很高。
iphone当然不是“这么”被破的
iphone是当初有人猜测MacOS用了有问题的libtiff,进而发现的确这个libtiff有问题。问题就是data overflow,然后就把exectuable stack的地址给覆盖了。
至于真正破解iphone的过程,当然不是文章中写的“这么”破解的。
jailbreak的那个exploit写的挺不错的,思路挺巧的。
说起来还是Apple在security方面重视程度不够,这方面微软可要领先一步,Vista早就已经能够把库函数和关键系统数据的地址随机化(ASLR)了。无他,被打怕了。
不过Apple最近也已经加了ASLR。
怎么把老文章翻出来了?