Security vuln on 4.3+4.4: overwrite any file/device with the string "Permission denied"

[pathorn]

This applies to any apps that request root permission and the user subsequently hits Deny. This only applies to 4.3+4.4 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.

Other notes for 4.3/4.4 from my testing: su does not need to be setuid. I don't know why the install scripts still insist on making it setuid. I have tested on my own device and it works fine without setuid because of the client/server model. [This is a better resolution to CVE-2013-6770 instead of whatever hack was put in to fix the immediate problem.]

Obviously this code is not maintained and 4.3/4.4 are ancient history. Please only install this unmaintained su binary if you know what you are doing or want/need open sourced code at the expense of security. If not, you are safer for now with the closed source alternatives. I'll see if I can put in the time to make a formal pull-request.

[javamaster999]

Hello
Ich antworte auf deutsch da ich gerade zu tun habe. Ich Bitte einfach um
eine schnelle und unbürokratische schnelle Hilfe (soll nicht unverschämt
klingen!).
Ich lerne gerade ziemlich viel auf verschiedenen Betriebssystemen und
gleichzeitig bin ich auch dabei einige Geräte wieder in stand zu setzen und
auf das mir mögliche Maximum an Leistung und Sicherheit herauszuholen. Da
habe ich hauptsächlich informations Bedarf (Linux /Perl /Grim...). Ich
werde mich später bei euch melden.
Danke im voraus 😉

Vielleicht habt ihr ja die Möglichkeit auf deutsch zu antworten meine Daten
habt ihr ja. Javamaster999 Roman N.
A...noch etwas wenn ihr etwas zur Absicherung braucht ich kann euch gerne
ein Foto von meiner Amtlichen Sicherheits Zertifizierung schicken a sign 03
prem 03
Freundliche Grüsse Roman
Am 04.01.2016 12:11 schrieb "Patrick Horn" notifications@github.com:

This applies to any apps that request root permission and the user
subsequently hits Deny This only applies to 43+44 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
classesdex

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

Other notes for 43/44 from my testing: su does not need to be setuid I
don't know why the install scripts still insist on making it setuid I have
tested on my own device and it works fine without setuid because of the
client/server model [This is a better resolution to CVE-2013-6770 instead
of whatever hack was put in to fix the immediate problem]

Obviously this code is not maintained and 43/44 are ancient history Please
only install this unmaintained su binary if you know what you are doing or
want/need open sourced code at the expense of security If not, you are
safer for now with the closed source alternatives I'll see if I can put in
the time to make a formal pull-request

—
Reply to this email directly or view it on GitHub
#284.

[MsRaelyn298]

Thanks
I could use all the help. Its been going on for a year. I think its time to fight back.

[sithsupersu]

yes I'm with you to fight back. I'm trying to get my root back.