[ROOT][SECURITY] Root exploit on Exynos

Because your shell is in graphics group.

if this is a Samsung kernel issue would any of the custom kernel have the same flaws? otherwise would I be able to workaround the problem by installing a CM10 ROM instead of stock?

Hey curio,

No need, here is a very quickly put together app in 5 mins that lets you toggle on/off world writability to /dev/exynos-mem

So you can toggle the fix off if you want to use the camera, then toggle it back on afterwards.
Github source: https://github.com/Ryan-ZA/exynosfix

APK Download: https://github.com/Ryan-ZA/exynosfix.../exynosfix.apk

Ryan

and to disable the exploit at boot (before any Android app runs).

Cannot protect efficiently against some potential attacks (typically, on boot).

First, thank you both for the hard work and quick release.

The main question here is, how efficient is the current implementation in both applications, regarding the protection at start up?

As long as I understand Chainfire somehow ensures that the fix will be applied before running any other (normal) application. Is it possible to install a new application, which to put itself on top of execution chain and exploit the hole, before your application is able to do a 0600 chmod?

If I understand correctly the supercurio's app doesn't promise anything on that matter?! If that is the case, then I guess the recommended app (for rooted phones) will be the Chainfire's solution, right?

Correct.

At the moment, Supercurio's method relies on Android starting it at boot, using the same method any Android app uses to launch at boot. There is no guaranteed order of these apps being launched, and as such, a malicious app could be executing malicious code before the exploit is disabled.

RyanZA's method relies on the same mechanism as well and as such is still vulnerable. Furthermore, unlike Supercurio's and my own patch, RyanZA's patch chmod's to 0600 while ours chmod to 0400. With 0600, system user can still run the exploit, so chaining a half-exploit that only gives system user followed by ExynosAbuse may still grant an attacker root access.

My method requires proper root and modifies /system, and disabling the exploit is done before any normal Android app (like those installed from the Play store) have a chance to execute their code. As long as you tell my app to disable the exploit at boot before you install a malicious app, and providing you do not grant a malicious app root (through SuperSU), this should protect against any exploit. Also note that after enabling applying the patch at boot, you can unroot in SuperSU again (SuperSU --> Settings --> Full Unroot) and the patch will keep working, but you'll be unrooted again (if you don't want root). On some devices it takes a reboot for SuperSU to truly disappear after that, by the way.

With my patch, I do advise testing the exploit was disabled after a reboot by running ExynosAbuse again, and verifying both checkboxes next to "Disable exploit" and "Disable exploit on boot" are enabled. These auto-detect the current state, and if the patch on boot was succesful both will be checked.

As a preliminary quick-fix the chmod could also be handled in ramfs to ensure it's applied as soon as possible in the boot process.

By the way chmodding to 600 didn't brake any of both cameras on a Samsung 4.1.2 based ROM using the old libs with an update 6 kernel on my dev. S3. Will check if it's also behaving like this on 4.1.1 later today.

just my $0.02.

Isn't this a matter of using specific usergroup for the device?

Besides the driver implementation side, instead of chmoding to 0400/0600?

I - creating a group like exynos-mem
II - chgrp exynos-mem /dev/exynos-mem
||| - chmod 0440, 0660 or 0640 to /dev/exynos-mem
|V - adding camera app user (and anyother that needs it) to exynos-mem

hmmm as far as I had a look on both apps from chainfire and supercurio, both set the permission for /dev/exynos-mem to c---------
edit: only supercurios app does that, chainfires app sets the permission to cr--------

anyway, both apps don't hinder executing successfully the original exploit from within an adb shell (exploit was stored on /data)