bugtraq - Android ICS "adb restore" directory traversal vulnerability (resending after bounce)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CAKXGCz6-XBKLNaAgcSLkpWhrYv-FL19zuuQkGRX85TJWHd_02Q@mail.gmail.com>
Date: Thu, 20 Jun 2013 17:39:05 +0300
From: Ariel Berkman <aberkman@...il.com>
To: bugtraq@...urityfocus.com
Subject: Android ICS "adb restore" directory traversal vulnerability
 (resending after bounce)

Hi,

adb (Android Debug Bridge) backup/restore allows you to backup and
restore applications via adb, including system applications.

The backed up files are stored in tar.zlib (named .ab by default)
files. "adb restore" is vulnerable to a directory traversal attack. By
creating a file named
"apps/com.andoird.settings/db/../../../local.prop" inside the backup
file, the restore operation would restore the file onto
/data/local.prop (rather than
/apps/apps/com.android.settings/databases/...).
The "apps","com.android.setttings" and "db" directory names are
extracted for determining the package name and the directory
(db=>database) to restore the relevant file onto, and everything that
follows is expected to be the filename.

This vulnerability is not specific to com.android.settings
(demonstrated below), but rather any system application that support
backup and restore.

One can use this vulnerability for escalating privileges to root on
Android phones supporting adb backup/restore (for example) as follows:

# tested on HTC phone with android 4.0.4.  This will likely work on
other configurations as well with some modifications.

# backup your settings app, before we overwrite its files.
adb backup -f settings.ab com.android.settings
(select approve to begin backup)

# restore the malformed backup file, which will create
/data/local.prop (with ro.kernel.qemu=1)  -- attached to this email.
adb restore special.ab

# restart the phone.

adb shell

# adb should now run as root.
# install SU, or create a setuid root shell somewhere.
# delete /data/local.prop

# the malformed backup file will likely break you settings app, so
expect some oddities until it's all restored.
adb restore settings.app

Bin4ry and later Saurik had used a race condition in "adb restore"
(http://forum.xda-developers.com/showthread.php?t=1886460) to gain
root, while this attack also uses adb restore, it uses a different
attack vector, and does not involve any race conditions.

Thanks,
Ariel.

--
Recover Information Technologies LTD.
http://www.recover.co.il

Download attachment "special.ab" of type "application/octet-stream" (1148 bytes)