Message-ID: <CAPRTkJiwFP0EgODr1A-xVr33ihocBmCU_qrbr9FXVZJmJ8wOKg@mail.gmail.com>
Date: Wed, 15 Aug 2012 19:15:34 -0500
From: Alexander Pruss <arpruss@...il.com>
To: bugtraq@...urityfocus.com
Subject: vulnerabilities in Samsung Epic 4G Touch with 2.3.6 and probably
 other Samsung Galaxies

[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@...il.com

Powered by blists - more mailing lists