主题：一篇讲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。

old thread

怎么把老文章翻出来了？