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.

# 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.