This Friday, I gave a presentation “Security Attack to 3D Printing” at XCON 2013 Beijing. I introduced technologies and toolchains of popular open-source 3D printer — RepRap, and generally discussed the security problems of the whole 3d printing system. At final part, I presented 3 demos about how to automatically modify Arduino board and RepRap Prusa Mendel’s firmware and change their behaviour. To the best of my knowledge, this is the first presentation talking about security problem of 3D printing.

My 110 pages’ slides can be downloaded from:

http://www.claudxiao.net/Attack3DPrinting-Claud-en.pdf (English)

http://www.claudxiao.net/Attack3DPrinting-Claud-zh_cn.pdf (Chinese)

And the PoC code is available at: https://github.com/secmobi/attack-arduino-and-reprap

去年和今年的一些安全会议中，我曾经提出如果一些具有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

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

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

乌云上发布了一个漏洞，称微信记录了用户微博账号的密码。地址是：

http://www.wooyun.org/bugs/wooyun-2013-020246

这个问题的产生原因并不复杂：微信使用webview加载微博的OAuth登录和认证页面，并采用了webview的默认设置。这种情况下，用户输入账户和密码登陆微博时，系统会弹出提示询问是否保存密码。如果用户选择了是，密码就会保存在这个应用私有目录的databases/webview.db中。

同样地问题还出现在许多流行的应用软件中。在我的手机里，至少小米、腾讯、百度等公司的产品都有发现。

危险性如何？由于密码保存在了/data/data/com.package.name/databases/webview.db中，至少这个软件是可以随便读取的。但我审计过上面这些软件的代码，没有发现实际读取和回传这一密码的情况。另一方面，其他应用需要root权限才能读取——至少在Google的安全模型假设里，系统是不应该被root的。不少恶意代码会利用漏洞提权，因此有获得这些密码的可能，但目前还没有这样的案例。

责任在谁？Google曾回信称，这是webview的一个特性，开发者应在具体使用时自己考虑安全性。在这个案例中，腾讯也把责任推给了webview。我的观点是，Android、软件开发商、用户三方都有责任。Android的错误在于，给webview的默认设置是提示用户是否保存密码，而不是默认不保存，以及对天下无root的假设也毫不实际；软件开发商的错误在于，没有更改这个默认设置，将选择权留给了用户，并事实上造成了第三方密码被明文存储（虽然并非主观故意）；用户的不当在于选择了保存——但这其实真的不能怪用户，不能要求大家理解这样一个会话界面的背后带来的诸多影响：

怎么修复？很简单，开发者在初始化webview实例后，加上一行代码：

theWebView.getSettings().setSavePassword(false);

就将其设置为不保存密码了。用户没有选择，也就避免了后面的问题。