SQLite Editor的一个安全缺陷

去年和今年的一些安全会议中,我曾经提出如果一些具有root权限的Android工具软件存在安全漏洞,也可能获得类似提权的利用效果。此前,我曾发文介绍过MIUI中定制的一款应用软件的组件暴露导致系统信息泄露。下面则是最近发现的另一个案例。

SQLite Editor是Speed Software开发的一款Android本地SQLite数据库文件查看器,在Google Play的购买和下载量为5万次以上。这些用户主要是Speed Software开发的另一款大名鼎鼎的工具Root Explorer带来。

当用户使用superuser类工具为SQLite Editor授予root权限后,使用它打开其他应用软件私有目录下的SQLite文件时,例如文件名为example.db,根据SuperSU Pro的记录,它会利用root权限将这个文件本身、这个文件的相关文件(包括可能存在的example.db-shm, example.db-wal, example.db-journal这三个文件)的other权限设置为可读和可写,然后以普通权限对该文件进行读取操作。在使用结束后,它会将example.db的other权限恢复为原来的值(通常为不可读、不可写)。但是,它忘了恢复example.db-journal的权限。因此,后者将继续保持other可读可写。这也就意味着,其他普通的应用软件现在开始也可以读写它了。

在Android中,example.db-journal文件是由SQLite透明地创建,用于缓存数据以便实现事务回滚机制。在我们的分析中,发现这类文件通常包含了大量example.db文件中存储的数据,包括但不限于用户的账户密码、用户的登陆token、用户的敏感隐私数据等。例如,我们知道Android的Email软件,以及老版本Android中的浏览器软件会将缓存的用户账号和密码明文地保存在本地的SQLite文件中。在其他一些涉及银行、支付等软件中,也会将登陆token存储在其私有目录下,受到Android安全机制的保护。然而,SQLite Editor的这一缺陷有可能导致这些密码或数据的缓存被所有其他软件读取。

这一问题的攻击面并不大,要成功利用它的前提条件非常多。但它已经足够作为典型案例,提醒Android系统中root权限工具的开发者以及系统的定制开发者,要更为严格地检查所写代码的安全性。

A .db-journal file becomes world readable and writeable

A .db-journal file becomes world readable and writeable

SuperSU Pro's log of SQLite Editor's root operations

SuperSU Pro’s log of SQLite Editor’s root operations

发表评论

电子邮件地址不会被公开。 必填项已用*标注