In some of security conferences last and this year, I’ve said that, if any Android utility tool with root permission has security vulnerability, this may lead to gaining privilege-escalation like ability. In last year, I’ve posted a component exposing vulnerability in a MIUI’s custom application which will leaks system information. Here I’ll introduce another case I discovered recently.
The SQLite Editor is an Android local SQLite database file viewer developed by the Speed Software. In Google Play, it has been purchased and downloaded in more than 50,000 times. Most of its users are introduced by another famous application — the Root Explorer — which is also developed by the Speed Software.
When users give SQLite Editor a root permission by tools like superuser, and then open SQLite files in other applications’ private directories, for example, a file named example.db, according to SuperSU Pro’s log, SQLite Editor will uses its root persmission to change the ‘other’ permission of this file and its related files (include may existings example.db-shm, example.db-wal and example.db-journal) to readable and writeable, and then read or write it by normal permission. After its operations finish, it will restore the ‘other’ permission of example.db to its original value (normally, unreadable and unwriteable). But, it forget to restore example.db-journal’s permission! Thus, the last file will keep readable and writeable by ‘other’ Linux users, which means, it can be read or wrote by other normal applications.
In the Android system, files like example.db-journal are transparently created by the SQLite library, and used for transaction roll back. By our analysis, we found that these files will contain huge content which belong to the ‘example.db’ files, include users’ account password, login token and sensitive privacy data. For example, we all know that the Email in Android and the Browser in old versions’ Android will plaintextly store users’ account and password. In other banking or payment applications’ databases, there’ll be login token and other information. These data should be protected by Android’s security mechanisms. However, this flaw of SQLite Editor will lead these cache of password or data to be read by other applications.
Of course, attack surface of this flaw isn’t wide. It need many pre-requirements to exploit it. But it’s enough to be a typical case to reminder root permission tools developers and system customization developers to more strictly check the security of their code.
A .db-journal file becomes world readable and writeable
SuperSU Pro’s log of SQLite Editor’s root operations
