DB2

安全漏洞：已知任一Dreamhost注册用户的主email地址，即可获得对该帐户的完全访问权限。 

适用范围：Dreamhost WebPanel

发现日期：2007-3-10

漏洞描述

在Dreamhost 注册的用户（包括免费帐户），均可通过修改自己的主email地址（primary e-mail contact address）为与系统中其他用户已设置的主email地址相同的方式，来获得对修改后的email地址原所属帐户的完全控制，被入侵用户正常的Dreamhost 服务不受影响，也不会受到任何警告和通知。

背景介绍

Dreamhost 的注册用户可以使用WebID 或者主email地址登录WebPanel ，管理帐户，WebID 由系统根据用户姓名自动生成，主email地址由用户在注册时提供，系统对两者都会进行唯一性检查，不允许重复。主email地址作为用户的联系方式，可以在profile 中随时进行更改，WebID 则不允许更改。

* NOTE-2: Each new Web ID MUST have a unique primary e-mail contact address! This is because you can log into the control panel either using your Web ID or your primary e-mail contact address. Also, the primary contact address is also the ONLY address that can be used for referrals! Additional address can also be added if you like, these can be duplicated across other Web IDs, but the primary contact address must be unique.

漏洞测试步骤 

1. 模拟用户A：在系统中注册免费帐户test1作为被入侵测试帐户，WebID为test1，主email 为test1@domain.com，密码：“111111”
2. 模拟用户B：在系统中注册免费帐户test2作为入侵测试帐户，WebID为test2，主email 为test2@domain.com，密码：“222222”
3. 用户B：登录test2帐户，编辑profile，将主email 地址修由test2@domain.com改为test1@domain.com，保存成功，退出登录
4. 用户B：检查test2@domain.com 收件箱，收到一封email地址变更通知
5. 用户A：检查test1@domain.com 收件箱，未收到任何来自Dreamhost的通知
6. 用户B：使用test1@domain.com 和密码“222222” 登录，登录成功，并且获得了与用户A 相同的访问控制
7. 用户B：使用WebID test1 和密码“222222” 登录，登录成功，获得对原有用户B 的资源访问。
8. 用户A：使用test1@domain.com 和密码“111111” 登录，一切正常

原因

在进行主email 变更时，系统未进行与注册步骤相同的email唯一性检查，致使作为用户唯一标识之一的主email 可能发生重复。Dreamhost 将会混淆两个原本完全不相关的帐户。结果是，用户A使用更改后的用户B的email 以及自己原有密码可以登录成功，并获得了用户B帐户的完全控制权，而那个不幸的用户B没有得到任何警告，他仍然可以使用自己的email 和密码正常登录自己的管理界面。

此时，Dreamhost WebID 并没有被搞混，用户A可以使用WebID 替代email，保持对自己原有帐户的访问。不过，很多用户大概不会留意WebID ， 有两个地方可以查知自己的WebID：

1. Dreamhost 发送的邮件主题，例如： [xxxxx 8729481] DreamHost Payment Receipt，xxxxx 就是WebID
2. 登录WebPanel，进入Edit Profile，界面显示："Welcome, xxxxx. Logout"，这里也能找到WebID

已将此问题反映给了Dreamhost 的Support Team，在问题得到修复之前，此篇日志不会被发布。

我会保持关注。

更新 2008-02-26

Dreamhost 已经修复此漏洞，下面是在profile 中修改主email的错误提示。

You cannot make sample@domain.com your primary address because another account already has it as its primary address!

今天查看网站日志，发现有trackback 进来，但都是403错误，使用自己的msn space进行测试，结果相同。车东给了解决方法：MT HTTP error: 403 Throttled的原因和解决，统计一下log中的trackback数量，一天有1000多条trackback，而且几乎全部是spam，

[hostname]$ grep mt-tb.cgi ./access.log.2007-03-18 |wc -l

1301

在我的mt-config.cgi加入如下2行

OneHourMaxPings 5000
OneDayMaxPings 20000

再次测试，日志中显示正常code 200，但页面并没有生成trackback 的引用。在Yee 这里 ，又找到了部分Dreamhost 主机不支持国内trackback过来的说法，于是，在此blog内部进行了trackback 测试，结果一切正常，证实了Yee 的说法。 

有趣的是，又有新的发现，在Junk TrackBacks 里面发现了几千个trackback，也包扩我在msn space 后来做的测试。虽然这不能说明Yee 的说法是错误的，但至少可以证明我不在那部分Dreamhost 主机当中。

Dreamhost 的空间已经用了个把月了（使用Fenng 的折扣代码购买 ），最欣赏的是它为用户提供登录Shell，在授权内可以运行绝大部分shell 命令，甚至允许添加cron job，让你在最大限度内保留自有主机的使用习惯。不过在带来灵活性的同时，如果使用不慎，风险也随之而来。下面是新建帐号系统默认建立的目录以及权限设置：

[hostname]$ pwd
/home/yourname
[hostname]$ ls -l
total 28
drwx--S---   6 yourname groupname 4096 2006-12-27 04:29 Maildir
drwxr-x--x  33 yourname groupname 4096 2007-02-03 06:07 domain.com
drwxr-sr-x   3 root       root      4096 2006-12-26 15:50 logs

目录domain.com 是对应虚拟主机网站所属的根目录，当前的权限位是drwxr-x--x(751)，网站如果希望被正常访问，所需的最小权限位是d--x--x--x(111)。而一般网站都有动态内容生成，比如使用cgi，那么作为运行此cgi 进程的用户则需要对相关目录和文件具有写权限，最小权限位是drwx--x--x(711)。

在深入讨论前，先回顾一下Unix 文件权限位的作用，如果你非常熟悉，请跳过。

每一个文件有10个标识位，第一位d代表目录，空(-)代表文件。其后9位分成三组，分别代表当前用户、同组用户、任何登录用户所对应的权限。r: 读权限，w: 写权限，x: 执行权限。这三种权限对于一个文件都很好理解，对于目录，如果拥有r读权限，可以列出目录下的文件，具有目录的w写权限和x执行权限，可以在目录中增加和删除文件。对于目录具有x执行权限，可以使用cd 命令进入此目录。

下面列出一些可能被误解的权限设置。 

例子一： 

drwx----wx /dir
-rwx------ /dir/1.txt

这种权限，虽然其他人无法列出目录dir 中的文件，也无法读取文件1.txt，但是如果已知文件名1.txt，依然可以删除文件，因为Unix 实际把目录也作为一个文件看待，目录实际保存了文件列表，对目录具有写权限就意味可以修改这个列表。

例子二：

drwx-----x /dir
drwx-----x /dir/dir2
-rwx---r-- /dir/dir2/1.txt

对于这种权限，其他人无法通过列目录方式获知文件路径/dir/dir2/1.txt ，但如果已知此路径，就可以读出文件内容。

安全漏洞 

默认的，Dreamhost 为你的home 目录设置如下权限：

[hostname]$ pwd
/home/yourname
[hostname]$ ls -ld .
drwxr-x--x  9 yourname groupname 4096 2007-02-03 06:00 .
 

这保证了任何本组以外的用户无法列出你的home 目录文件，但并不保证无法列出home 目录以下的子目录，这依赖于你的权限设置，而大多数用户都设置了一个非常宽松的权限。有关Dreamhost用户组的设置，下一个小节会讨论。

例子二就是本文讨论的目的，前面说过，对于网站所属的目录，为了保证正常浏览，对于所有目录都要求设置一个最小权限d--x--x--x(111)，同时对于网站目录中的cgi 文件，我们通常设置为drwxr-xr-x(755)，如果一个不怀好意者拥有一个与你相同主机上的shell 帐户，可以通过猜测或者其它途径获得你的敏感文件路径，然后使用以下命令轻松获得你的敏感信息，比如，人们通常把movable type 系统的数据连接信息保存在文件mt-config.cgi 中。

$ cat /home/yourname/yourdomain.com/mt/mt-config.cgi 

对于上面的安全问题，我有2种解决方法，一种是让人无法获知敏感文件的准确路径，但是这种方法非常具有局限性，即使实现，管理成本也很高。Dreamhost 已存在的一个安全漏洞使大部分未觉察的用户都暴露在此风险下。另一种方法是小心的配置敏感文件的权限，而对于非敏感文件则可以不作考虑。比如对于mt-config.cgi 文件，应该设置权限-rw-------(600)，此文件虽然具有cgi 扩展名，不过仅仅是一个配置文件，只要保证以你的帐户身份运行的cgi 程序可以读取此文件即可。对于其它类似的敏感文件可根据情况进行类似权限设置。

更多的讨论

Dreamhost 允许用户建立多个shell 帐户，如果你打算同其他人share 你的host 空间，或者为你的朋友提供hosting，大概就需要为他们创建shell 登录帐户。默认的，这些新建的帐户将与你自己的帐户拥有相同的group，这个默认行为提供了一定的便利性，但也似乎无法改变，需要引起注意。应该根据情况，小心的为你自己的目录和文件设置组权限，并提醒与你share 主机的朋友做好自己的组权限设置（你们在同一个group 内），权限rwxrwx--- 黄底色的部分将影响到你们之间的关系。

如果确定了一个自己认为安全的权限位，并且适合大多数情况，则可以将此权限写入默认设置，使新建的目录和文件自动拥有此设置。这通过umask 命令 实现，并将其写入自己的profile 中。在Dreamhost 此文件位于 /home/yourname/.bash_profile， 并具有如下默认设定：

umask 002

今天准备在Dreamhost 上自动备份blog的DB，MySQL是Dreamhost唯一提供的关系数据库服务，当前版本5.0 我了解很少（这里有个学习笔记 ），已知可以在命令行使用mysqldump 命令备份整个数据库，备份时似乎无需了解数据库的当前状态（比如是否正在运行事务），它会自行处理，从备份出的文件看，mysqldump实现的是冷备份，也就是说，仅采用这种备份方法，数据仅能恢复到最后一次运行mysqldump的时间点。

MySQL也介绍了一个热备份工具mysqlhotcopy，不过文档中有以下声明，我不清楚什么是MyISAM 与ARCHIVE tables，也不大明白MySQL 热备份的恢复机制（如何前滚日志）。还好，我的数据库目前很小，而我的空间很大很大，每次全备份只花费很少的时间，也占用很小的空间。

mysqlhotcopy works only for backing up MyISAM and ARCHIVE tables. It runs on Unix and NetWare.

使用mysqldump备份出来的文件，是一个包含了sql语句的文本文件，含有建表语句以及Insert语句。我采用这种方式恢复：连接到mysql进入mysql提示符，创建一个db（如果不存在），连接到此db，执行备份文件，如：

mysql> source ./mybackup.sql 

执行结束则恢复完毕。这里有篇日志 介绍了另外一种恢复方法（如下），不过我没有尝试过。 

$ mysqldump -u root -p'123456' test2 < samp.db.txt 

言归正传，我准备采用crontab 自动运行mysqldump 来自动备份数据库。写了一个shell脚本如下，备份文件使用当前系统时间（到分钟）作为文件名，备份成功后进行压缩。

backupdb.sh 

bakfile=~/xxx/mt-db_`date '+\%Y\%m\%d\%H\%M'|tr -d '\\\'`.sql
mysqldump -hmysql.mydomain.com -umyname -pmypasswd mt > $bakfile
gzip $bakfile
exit 0

然后在crontab中加入条目，定时自动运行此脚本。这里设置为每4个小时，在整点运行一次，每天产生一份日志。

00 0-23/4 * * * ~/xxx/backupdb.sh >> ~/xxx/logs/backupdb_`date '+\%Y\%m\%d'|tr -d '\\\'`.log 

经试验`date '+\%Y\%m\%d'|tr -d '\\\'`部分似乎不能被cron命令成功替换，但是在shell中是可以成功执行的。

$ echo backupdb_`date '+\%Y\%m\%d'|tr -d '\\\'`.log
backupdb_20070127.log