Affected Devices:
Vulnerabilities verified on Samsung Galaxy S2 for Sprint-US (Epic 4G Touch), with EL29 firmware (Android 2.3.6). Some, but likely not all, of these vulnerabilities are probably present on ICS and on other Samsung Galaxy series devices, but they have not been tested significantly there. Reader testing is welcome--I don't have other Samsung devices for testing myself, and have no desire to upgrade to ICS to test.
Summary
The directories /data/log, /data/anr and /data/_SamsungBnR_ are world-writeable.
On ICS on the Galaxy S2, I have not verified the presence of /data/_SamsungBnR_, but based on a file listing sent by a user, /data/log and /data/anr are writeable by the log group, which includes both the adb shell and applications with the misleadingly named READ_LOGS permission.
A number of files are written in these directories by processes running with root or system privileges, with the resultant files having world-write (or log-group write on ICS?) permissions. This allows malicious apps with READ_LOGS permission, or users using the adb shell, to replace the exploitable files with symbolic links which will result in the creation or (in most cases) overwriting of arbitrary files on rw-mounted partitions.
This can be exploited to gain local root for the adb shell as in the motofail exploit by putting appropriate content in /data/local.conf . It can also be exploited to destroy user data, to deny service by destroying or modifying essential files, etc.
There are several exploits possible here. In all cases, the exploit will have the
following structure:
1. Delete existing vulnerable file in vulnerable directory if already existing.
2. Make a symbolic link from the vulnerable file to a target file.
3. Trigger the system process that overwrites the vulnerable file.
4. If desired, remove symbolic link and write desired content to target file.
The details give the specific vulnerable files and the methods for triggering the
relevant system processes. Some of these processes require user intervention and would require a malicious app either to trick the user into the intervention or simply to wait for the user to trigger the process on their own at a later point.
Details of vulnerable files:
I. /data/log/recovery_log.txt and /data/log/recovery_kernel_log.txt
These world-writeable files are written to whenever the device's recovery console runs.
On the S2, this is triggered by turning off the device, and then holding the volume-up and power buttons.
Once the recovery console starts, one can continue to normal boot by pressing home.
Replacing one of these files with a link to /data/local.conf will make for invalid data in /data/local.conf, but on the tested device linking recovery_log.txt to local.conf did not impede boot.
The file created by this method has 666 permissions and root.root ownership.
Exploiting this vulnerability in an application requires the user to perform the highly suspicious action of turning off the phone and booting to the recovery console. Nonetheless, a malicious app could make the symbolic link with a view to users running the recovery console on their own at a future date. However, ordinary users probably do not run the recovery console.
II. /data/log/gyroOffset
This world-writeable file is overwritten by the gyroscope calibration in the system display settings.
The gyroscope calibration runs as system rather than as root, and the ability of using this vulnerability to replace existing files with arbitrary content is thus somewhat limited. In particular, while this creates new files with 666 permissions, it leaves intact permissions of existing files, and will not overwrite root-owned files with 644 permissions.
Nonetheless, as long as one does not have a pre-existing /data/local.conf file, this is sufficient for gaining adb root and probably some damage.
Exploiting this vulnerability in an application requires the user to calibrate the gyroscopes, which is not a particularly suspicious action. Alternately, a malicious app could wait for users to do this on their own.
III. /data/log/dumpstate_app_error.txt.gz.tmp, /data/log/dumpstate_app_anr.txt.gz.tmp, /data/anr/traces.txt and perhaps other /data/log/dump* files
These files get written when the relevant error condition occurs. The system then renames the *.gz.tmp file to *.gz. These vulnerable files can be used to overwrite or create files, and to place new content in them.
This is the most serious of the set of vulnerabilities, at least on the Gingerbread-based S2, because the condition can be triggered with no user intervention beside running the malicious application. The user will see the malicious application crash, which is suspicious.
IV. /data/_SamsungBnR_/BR/*.bk and perhaps /data/_SamsungBnR_/BR/*/*.bk
These world-writeable files are periodically updated with backup data, with the backup process apparently running with system privileges. Like /data/log/gyroOffset, this cannot overwrite all files, but it is sufficient for gaining adb root and probably some damage.
The backup process that creates these files can apparently be triggered with an appropriate intent from an application or a commandline, or a malicious application can simply wait for this to happen in due course. For instance, /data/_SamsungBnR_/BR/Message.bk will be overwritten upon executing: am broadcast -a com.sec.mms.action.BACKUP_FINISH
V. Others?
/dbdata/databases, /data/clipboard, /data/factory and /data/misc/dhcp all have 777 permissions on the tested device, but an exploit using files in these directories has not been found as yet.
VI. Final remarks
These vulnerabilities should have been fixed as soon as it became public how motofail worked, since they can all be quickly found by looking for directories that are world- or log-writeable.
Alex Pruss Omega Centauri Software
https://play.google.com/store/apps/developer?id=Omega+Centauri+Software
-- Alexander R. Pruss
arpruss () gmail com
RSS Feed