This applies to any apps that request root permission and the user subsequently hits Deny. This only applies to all versions 4.3+ which use client/server instead of the traditional setuid model. The attacker only needs the ability to run executable code (such as embedded in a "libs" directory).
[exploit details withheld: contact me to discuss]
After the exploit code is run by an untrusted user, the user is presented with a permission request screen. Obviously there is no problem if the user allows permission. However, if the user denies permission, the string "Permission denied" is written into the file of the attacker's choice. This could have any number of consequences. Clearly this can be used to brick the phone. For example I could pass /dev/block/mmcblk0p40 and stick "Permission denied" at the beginning of the user's baseband or fastboot partition. Or I could break any apps on the writable data partition by overwriting their classes.dex.
The permission request screen can be easily hidden with a bit of WindowManager, Toast or Intent magic to get out of there before it even loads.
I don't know yet if the Permission denied string can be changed, but even as is, it means rogue apps can damage the phone which is pretty scary.
(Aside: thank you for fixing CVE-2013-6770 properly by removing the setuid bit. I had no idea this fork existed until after I reported my other bug.)
[x-post from https://github.com/koush/Superuser/issues/284]
This applies to any apps that request root permission and the user subsequently hits Deny. This only applies to all versions 4.3+ which use client/server instead of the traditional setuid model. The attacker only needs the ability to run executable code (such as embedded in a "libs" directory).
[exploit details withheld: contact me to discuss]
After the exploit code is run by an untrusted user, the user is presented with a permission request screen. Obviously there is no problem if the user allows permission. However, if the user denies permission, the string "Permission denied" is written into the file of the attacker's choice. This could have any number of consequences. Clearly this can be used to brick the phone. For example I could pass /dev/block/mmcblk0p40 and stick "Permission denied" at the beginning of the user's baseband or fastboot partition. Or I could break any apps on the writable data partition by overwriting their classes.dex.
The permission request screen can be easily hidden with a bit of WindowManager, Toast or Intent magic to get out of there before it even loads.
I don't know yet if the Permission denied string can be changed, but even as is, it means rogue apps can damage the phone which is pretty scary.
(Aside: thank you for fixing CVE-2013-6770 properly by removing the setuid bit. I had no idea this fork existed until after I reported my other bug.)