Samsung Galaxy S2 World Writeable Directories

2012-08-17T00:00:00
ID PACKETSTORM:115620
Type packetstorm
Reporter Alexander R. Pruss
Modified 2012-08-17T00:00:00

Description

                                        
                                            `[Note: I really don't know much about how one writes up vulnerabilities and  
exploits. I just wanted to root my phone, and found the following apparently  
previously unknown vulnerabilities. I reported them to Samsung two weeks ago.]  
  
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  
`