2011年10月9日
摘要: 如果还有人记得我当年发在80sec上的那篇《Linux 系统文件描述符继承带来的危害》的话，应该记得当时这个问题已经被apache官方使用FD_CLOSEXEC修复了：由于在系统底层exec其他进程的时候，所有开启的FD就会被自动关闭，因此就没有办法使用system等php函数，在子进程如bash中继续操作原有开启的高权限文件描述符。
但是最近PHP 5.3.6引进了一个新特性：利用fopen("php://fd/fd_number", "w")的形式，可以直接打开并操作当前进程的文件描述符。基本相当于一个fdopen函数调用。
结合这两点，由于php本身的一种运行方式是以apache的mod方式在apahe进程中存在的，所以对于php来说，他的自身进程也就是apache的进程，所有apache原来在root下打开的文件描述符，他都能操作。于是乎，原有修补完毕的漏洞，经过PHP新功能的妙手回春，又重现江湖了。
阅读全文
2011年8月18日
摘要: Author: wofeiwo
Date: 2011-08-18
Mongodb，这么火的玩意其实早就想好好研究一下了。之前一直没空仔细学学新的东西，总是感觉精力不足。这次趁着买了一本书，就零零散散地在VPS上搭建、测试、看实现代码。感觉也蛮有意思的一个数据库。虽然感觉它非常简单，尤其是看代码的时候更是感觉如此。但这不也是另一个KISS的典范么，还是简单但是实用的东西最能流行。
既然都看了其实现，也不能不产出点什么。正好多年没更新博文，就简单分析一下mongodb的安全性，凑个数先。 阅读全文
2010年12月10日
今天发布的PHP新版本5.3.4，从Changelog来看修补了不少安全漏洞。
其中最引人注意的是这一条：
Paths with NULL in them (foo\0bar.txt) are now considered as invalid (CVE-2006-7243).
看到时被惊到了，PHP对于这种说不清是PHP的漏洞还是操作系统漏洞 -- 甚至根本只能算是特性的边缘问题 -- 向来都是修复及其缓慢的，而且极善于推卸责任。例如在80sec发的那篇FD继承的文章中提到的问题，03年PHP就收到bug报告了，但他就是硬撑着不肯用apache提供的安全文件操作api，而是自己写一套实现，还老是说这是apache的安全问题，死活拖了足足6年也不肯修复。还有那个php+fastcgi的解析问题也是同样如此，可见PHP是多么劣迹斑斑。 这次PHP也总算是有点动作了，解决了一个遗留的老大难问题（看看那个cve号的日期）。这一次PHP手脚很干净，对所有涉及到文件操作的PHP函数都做了检查，比对strlen(文件名)和收到的文件名变量长度是否一致，从而保证了文件名不会被截断。（参考base_functions.c和file.c） 这意味着：从今晚后所有PHP文件操作中，文件名NULL字符截断的问题将被永久性解决了。什么上传截断啊、本地包含截断啊、读文件截断啊之类的统统干掉，因此非常推荐各位PHP用户升级5.3.4。
那么，是否还有其他办法来进行文件截断呢？这个，知者不具言，你懂得。
2010年8月20日
参见：http://forge.mysql.com/wiki/MySQL_Internals_ClientServer_Protocol#Password_functions
我意译一下，大致就是以下内容：
4.0版本之前
- 1、服务器发送随机字符串（scramble_buff）给客户端.
- 2、客户端把用户明文密码加密一下，然后将hash加上服务器的随机字符串加密一下变成新的scramble_buff。（参见sql/password.c:scramble()）.
- 3、客户端将加密后的scramble_buff值发给服务端.
- 4、服务器将mysql.user.Password的值加上原始随机字符串进行加密.
- 5、服务器比对加密后的hash值和服务端送过来的加密后的scramble_buff.
- 6、如果一样，则验证成功.
基本就是一个挑战机制。但是注意一点：实质上真正意义上的密码是明文密码的加密hash值; 如果有人知道了这个用户的mysql.user.Password（而不用知道原始明文密码）他就能直接登录服务端.
4.1以后版本
4.1以后数据库保存的密码是用SHA1加密的：SHA1(SHA1(password))
- 1、服务器发送随机字符串（scramble）给客户端.
- 2、客户端作如下计算:
- stage1_hash = SHA1(明文密码).
- token = SHA1(scramble + SHA1(stage1_hash)) XOR stage1_hash
- 3、客户端将token发送给服务端
- 4、服务端作如下计算：
- stage1_hash = token XOR SHA1(scramble + mysql.user.Password)
- 5、服务端比对SHA1(stage1_hash)和mysql.user.Password，如果匹配，则认证正确。
注意：SHA1(A+B)意思是SHA1（A字符串连接B字符串）.
这次没上一个版本的缺陷了. 有了mysql.user.Password和scramble也不能获得token。因为他没法获得stage1_hash。
但是如果这人有这用户的 mysql.user.Password 及网络上截取的一次完整验证数据, 他也能根据这次截获的token和scramble反解出stage1_hash的值。而由于stage1_hash是不变的，因此下次连接，他获取了新的scramble后，自己加密一下token，送给服务端也能通过验证而连接到服务器.
最后放一个5.1的认证的抓包结果，注意标红的地方：
server > 127.0.0.1.49130: Handshake <proto 10 ver 5.1.41-3ubuntu12.6 thd 55 scramble 1EGu9\Aq8_UnI_'@L<*Y >
127.0.0.1.49130 > server: Handshake (new auth) <user root db (null) token 6d2c7025c412b997788525b19a5167c89dafcbe max pkt 16777216>
server > 127.0.0.1.49130: OK <fields 0 affected rows 0 insert id 0 warnings 0>
2008年9月29日
说个很没水平的漏洞.
最近做项目,客户说他的Pligg常常被spam.结果去后台删除comments的时候被xss了.而Pligg是我刚升级到的最新版本9.9.5
检查了一下story.php和libs/comment.php,发现难怪如此.
comment虽然提示是html disable的.但是入数据库前根本除了escape一下根本未作任何过滤..太不设防了..赶紧加了点过滤,不过相信问题还是有不少的.
虽然Pligg是个常用的open source Digg系统,但是居然这么高版本了还对安全如此不负责任.report到官方论坛,一个礼拜了也没人理.