5,605,373 Members 41,395 Now Online
XDA Developers Android and Mobile Development Forum

[ROOT][SECURITY] Root exploit on Exynos

Tip us?
 
Entropy512
Old
#11  
Senior Recognized Developer
Thanks Meter 23432
Posts: 12,791
Join Date: Aug 2007
Location: Owego, NY

 
DONATE TO ME
Quote:
Originally Posted by supercurio View Post
Because your shell is in graphics group.
I was beginning to suspect that, thanks for confirming.

Quote:
Originally Posted by dennis.l View Post
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?
Right now older custom kernels will. CM's codebase was just patched earlier today to restrict that node to system.graphics 0660

It was done in the 10.1 branch, so it won't immediately affect all devices. We're working on transitioning all exynos4 devices over to 10.1 this week - it's about halfway done.
*so much sig updating needed*

My Github profile - Some Android stuff, some AVR stuff

An excellent post on "noobs vs. developers"

A few opinions on kernel development "good practices"

Note: I have chosen not to use XDA's "friends" feature - I will reject all incoming "friend" requests.

Code:
<MikeyMike01> Smali is a spawn of hell
<shoman94> ^^^ +!
Code:
<Entropy512> gotta be careful not to step on each other's work.  :)
<Bumble-Bee> thats true
<jerdog> compeete for donations
The Following 3 Users Say Thank You to Entropy512 For This Useful Post: [ Click to Expand ]
 
supercurio
Old
#12  
supercurio's Avatar
Senior Recognized Developer
Thanks Meter 5063
Posts: 3,528
Join Date: May 2010
Location: Chambéry

 
DONATE TO ME
@alephzain, when running the exploit in an adb shell, sometimes the privilege escalation fails with:

Code:
[*] s_show->seq_printf format string found at: 0xC07A70A8
[*] sys_setresuid found at 0xC00945A0
[*] patching sys_setresuid at 0xC00945E4
[!] set user root failed: Operation not permitted
And it typically succeed after 1 or 2 more attempts.
Does it ring a bell?
 
Chainfire
Old
#13  
Chainfire's Avatar
Senior Moderator / Senior Recognized Developer - Where is my shirt?
Thanks Meter 46119
Posts: 8,834
Join Date: Oct 2007

 
DONATE TO ME
Default ExynosAbuse APK updated to v1.10

I've just updated the ExynosAbuse APK to v1.10 !

This version allows you to disable the exploit (which may break camera), re-enable the exploit (if you need the camera) and to disable the exploit at boot (before any Android app runs). These options do require root (SuperSU or Superuser) to be installed as well. This is for people who actually *want* root. If you don't want root, you should use Supercurio's solution as it doesn't depend on being rooted it for dis/reenabling the exploit.

http://forum.xda-developers.com/show....php?t=2050297
BLOG - G+(Chainfire) - G+(Personal) - TWITTER - IRC - DONATE

A proper quote includes only the relevant paragraphs, and a proper post never ends with the word "why"

Android
HTC G1, Hero, One
Samsung i5800, i9000*2, P1000*2, P7100, i9100*2, N7000, P6800, i9300, N7100, i9505, N9005
Sony T LT30p, Z C6603
Nexus Galaxy*2, N7, N10, N7-2013

SuperSU, Mobile ODIN, TriangleAway, DSLR Controller, CF-Root, 500 Firepaper, OpenDelta, USB Host Diagnostics, ExynosAbuseAPK, Live dmesg+logcat, NoMoarPowah!, CF-Bench, Chainfire3D, CF.lumen, SGS2 SIM Unlocker, GingerBreakAPK, SuperPower, and more!

Windows Mobile 5/6
E-Mobile EM-ONE
HTC Wizard*2, Kaiser, Touch, Diamond, Pro, HD*2, Diamond 2, Pro 2*2, HD2*2
Samsung i780, i900*2, i8000*2, b7300, b7320, b7330, b7620*2, b6520

WMWifiRouter, KaiserTweak, FPUEnabler, WMLongLife, WMRegOptimizer, CFC+GUI, TF3D+v2 ports, Kaiser+Omnia2+Snapdragon 3D drivers, GfxBoost, and more!

Windows Phone 7
LG GW910

NOTICE: I do not respond to tech support questions through PM.
The Following 25 Users Say Thank You to Chainfire For This Useful Post: [ Click to Expand ]
 
supercurio
Old
(Last edited by garyd9; 17th December 2012 at 02:16 PM.) Reason: link to XDA thread for the specific solution
#14  
supercurio's Avatar
Senior Recognized Developer
Thanks Meter 5063
Posts: 3,528
Join Date: May 2010
Location: Chambéry

 
DONATE TO ME
Voodoo Instant fix for Exynos Mem Abuse vulnerability released.

I'm glad I have a blog, because things tend to disappear here ^^

Edit: Please use the following thread to discuss this specific solution: http://forum.xda-developers.com/show....php?t=2051290
The Following 18 Users Say Thank You to supercurio For This Useful Post: [ Click to Expand ]
 
RyanZA
Old
#15  
Senior Member
Thanks Meter 726
Posts: 2,021
Join Date: Jan 2006
Location: JHB
Quote:
Originally Posted by RyanZA View Post
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
As per requests, I added in 'fix vulnerability on boot' functionality for those who like an open source fix.

Nice work on that app, curio.
Need stuff done? Give me a shout, maybe I can help: http://www.mobile-dev.co.za/
The Following User Says Thank You to RyanZA For This Useful Post: [ Click to Expand ]
 
AndreiLux
Old
(Last edited by AndreiLux; 18th December 2012 at 08:11 PM.)
#16  
AndreiLux's Avatar
Senior Member
Thanks Meter 13339
Posts: 2,653
Join Date: Jul 2011

 
DONATE TO ME
Sooooo....

Here's a low-level fix for the kernel.

Source @ https://github.com/AndreiLux/Perseus...94a400c6b40a71
Edit: Follow-up commit for Note 2 (Possibly N8000 too) users @ https://github.com/AndreiLux/Perseus...4e42c791f0813e

I did what I said in the first post. The mmap function checks the given memory addresses against all of the current CMA memory spaces on the device and denies access if the space it out of bound of any of the defined blocks. Furthermore on my S3 I, for now, couldn't find anything breaking beyond the main camera. So I added an additional condition that checks that the accessed memory block is "s3c-fimc" (The camera DMA block) and ignores the other blocks. The whole thing is totally neutered if CONFIG_CMA_DMA isn't used in the device configuration (Note 2 / Exynos 4412 devices with 2GB RAM). Edit: Fix works now the same for all devices.
Defined memory spaces:
Code:
[    0.000000] c0 cma: CMA: reserved 16 MiB at 65800000
[    0.000000] c0 [cma_region_descriptor_add] adding [s3c-fimc] (0x65800000)-(0x00f00000)
[    0.000000] c0 cma: CMA: reserved 40 MiB at 5c800000
[    0.000000] c0 [cma_region_descriptor_add] adding [s3c-mfc] (0x5c800000)-(0x02800000)
....
....
[    0.000000] c0 S5P/CMA: Reserved 0x70000000/0x00a00000 for 'fimc_is'
[    0.000000] c0 [cma_region_descriptor_add] adding [fimc_is] (0x70000000)-(0x00a00000)
[    0.000000] c0 S5P/CMA: Reserved 0x71700000/0x00800000 for 'fimd'
[    0.000000] c0 [cma_region_descriptor_add] adding [fimd] (0x71700000)-(0x00800000)
[    0.000000] c0 S5P/CMA: Reserved 0x6c300000/0x03d00000 for 'fimc0'
[    0.000000] c0 [cma_region_descriptor_add] adding [fimc0] (0x6c300000)-(0x03d00000)
[    0.000000] c0 S5P/CMA: Reserved 0x71600000/0x00100000 for 'srp'
[    0.000000] c0 [cma_region_descriptor_add] adding [srp] (0x71600000)-(0x00100000)
[    0.000000] c0 [cma_region_descriptor_add] adding [mfc-normal] (0x64000000)-(0x00400000)
[    0.000000] c0 S5P/CMA: Reserved 0x64000000/0x00400000 for 'mfc-normal'
[    0.000000] c0 [cma_region_descriptor_add] adding [mfc-normal] (0x64000000)-(0x00400000)
[    0.000000] c0 S5P/CMA: Reserving 0x6800000 for secure region aligned by 0x4000000.
[    0.000000] c0 S5P/CMA: Reserved 0x5c000000/0x06800000 for 'secure_region'
[    0.000000] c0 S5P/CMA: Reserved 0x5c000000/0x00800000 for 'sectbl'
[    0.000000] c0 [cma_region_descriptor_add] adding [sectbl] (0x5c000000)-(0x00800000)
[    0.000000] c0 S5P/CMA: Reserved 0x5c100000/0x03100000 for 'mfc-secure'
[    0.000000] c0 [cma_region_descriptor_add] adding [mfc-secure] (0x5c100000)-(0x03100000)
[    0.000000] c0 S5P/CMA: Reserved 0x5f200000/0x02f00000 for 'ion'
[    0.000000] c0 [cma_region_descriptor_add] adding [ion] (0x5f200000)-(0x02f00000)
Running the exploit:
Code:
u0_a60@android:/ $ export PATH=/data/local/bin:$PATH
 u0_a60@android:/ $ ./exynos-abuse
 [!] Error mmap: Invalid argument|00000004
Behind the scenes during that:
Code:
[ 119.290791] c1 [exynos_mem_open:50] private_data(0xd0340b80)
 [ 119.290889] c1 [exynos_mem_mmap] requesting access to (0x40000000)-(0x41000000)
 [ 119.290960] c1 [exynos_mem_mmap] Checking space paddr(0x65800000)-(0x66700000) from 's3c-fimc'
 [ 119.291046] c1 [exynos_mem_mmap] Checking space paddr(0x5c800000)-(0x5f000000) from 's3c-mfc'
 [ 119.291299] c1 [exynos_mem_mmap] Checking space paddr(0x70000000)-(0x70a00000) from 'fimc_is'
 [ 119.291386] c1 [exynos_mem_mmap] Checking space paddr(0x71700000)-(0x71f00000) from 'fimd'
 [ 119.291465] c1 [exynos_mem_mmap] Checking space paddr(0x6c300000)-(0x70000000) from 'fimc0'
 [ 119.291545] c1 [exynos_mem_mmap] Checking space paddr(0x71600000)-(0x71700000) from 'srp'
 [ 119.291631] c1 [exynos_mem_mmap] Checking space paddr(0x64000000)-(0x64400000) from 'mfc-normal'
 [ 119.291711] c1 [exynos_mem_mmap] Checking space paddr(0x64000000)-(0x64400000) from 'mfc-normal'
 [ 119.291801] c1 [exynos_mem_mmap] Checking space paddr(0x5c000000)-(0x5c800000) from 'sectbl'
 [ 119.291888] c1 [exynos_mem_mmap] Checking space paddr(0x5c100000)-(0x5f200000) from 'mfc-secure'
 [ 119.291967] c1 [exynos_mem_mmap] Checking space paddr(0x5f200000)-(0x62100000) from 'ion'
 [ 119.292034] c1 [exynos_mem_mmap] invalid paddr(0x40000000)-(0x41000000), accessing outside of DMA spaces
 [ 119.292798] c1 [exynos_mem_release:58] private_data(0xd0340b80)

I didn't care about the permissions set to the sysfs interface as they don't matter anymore.

I'll be deploying the fix tomorrow throughout my kernels.

The only things that needs to be checked by then is if something else breaks, as HDMI or so. I can't test any of that since I don't have a dongle. In that case anyway the kernel log will tell you what other memory space is accessed and I can open that one up too if needed.

Note: Galaxy S2 / 4210 developers may have to add cma_region_descriptor_add calls to from wherever the memory blocks are defined (Machine file definition or arch/arm/plat-s5p/reserve_mem.c). My commit will work as is on S3 and N2 sources.

I'm off to bed.
The Following 105 Users Say Thank You to AndreiLux For This Useful Post: [ Click to Expand ]
 
julandroid
Old
(Last edited by julandroid; 17th December 2012 at 09:42 AM.)
#17  
Member
Thanks Meter 1
Posts: 34
Join Date: Jun 2011
Quote:
Originally Posted by Chainfire View Post
and to disable the exploit at boot (before any Android app runs).
Quote:
Originally Posted by supercurio View Post
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?
 
Chainfire
Old
(Last edited by Chainfire; 17th December 2012 at 02:11 PM.)
#18  
Chainfire's Avatar
Senior Moderator / Senior Recognized Developer - Where is my shirt?
Thanks Meter 46119
Posts: 8,834
Join Date: Oct 2007

 
DONATE TO ME
Quote:
Originally Posted by julandroid View Post
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 or 0000. 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.
BLOG - G+(Chainfire) - G+(Personal) - TWITTER - IRC - DONATE

A proper quote includes only the relevant paragraphs, and a proper post never ends with the word "why"

Android
HTC G1, Hero, One
Samsung i5800, i9000*2, P1000*2, P7100, i9100*2, N7000, P6800, i9300, N7100, i9505, N9005
Sony T LT30p, Z C6603
Nexus Galaxy*2, N7, N10, N7-2013

SuperSU, Mobile ODIN, TriangleAway, DSLR Controller, CF-Root, 500 Firepaper, OpenDelta, USB Host Diagnostics, ExynosAbuseAPK, Live dmesg+logcat, NoMoarPowah!, CF-Bench, Chainfire3D, CF.lumen, SGS2 SIM Unlocker, GingerBreakAPK, SuperPower, and more!

Windows Mobile 5/6
E-Mobile EM-ONE
HTC Wizard*2, Kaiser, Touch, Diamond, Pro, HD*2, Diamond 2, Pro 2*2, HD2*2
Samsung i780, i900*2, i8000*2, b7300, b7320, b7330, b7620*2, b6520

WMWifiRouter, KaiserTweak, FPUEnabler, WMLongLife, WMRegOptimizer, CFC+GUI, TF3D+v2 ports, Kaiser+Omnia2+Snapdragon 3D drivers, GfxBoost, and more!

Windows Phone 7
LG GW910

NOTICE: I do not respond to tech support questions through PM.
The Following 20 Users Say Thank You to Chainfire For This Useful Post: [ Click to Expand ]
 
Yank555
Old
#19  
Yank555's Avatar
Senior Member
Thanks Meter 9074
Posts: 5,892
Join Date: Sep 2009
Quote:
Originally Posted by Chainfire View Post
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.

JP.

Sent from my custom Paranoid Android 2.54 / Yank555.lu CM10 kernel v1.3b Aroma (Linux 3.0.56) powered Galaxy S3 i9300 using Tapatalk 2
Note 3 N9005 32Gb Proudly eFused
64Gb FAT32 / JB bootloader / CM11 (hltexx) / CWM / 1Gb zSwap
Yank555.lu AOSP kernel v0.91-beta7 (3.4.85)

Kernels : AOSP v0.9 (3.4.78) / JB-TW 4.3 v0.8

SGS3 I9300 32Gb
32Gb FAT32 / CWM

Kernels : OMNI/CM11 v1.7 (3.0.101) for i9300 & v1.6g (3.0.101) for i9305 / Samsung U13 v4.2 (3.0.101) for i9300 & U12 v4.0+ (3.0.101) for i9305

HTC Sensation XE
HTC HD2
TF300TG 32Gb



Credits FAdrums !
The Following User Says Thank You to Yank555 For This Useful Post: [ Click to Expand ]
 
Chainfire
Old
#20  
Chainfire's Avatar
Senior Moderator / Senior Recognized Developer - Where is my shirt?
Thanks Meter 46119
Posts: 8,834
Join Date: Oct 2007

 
DONATE TO ME
Quote:
Originally Posted by Yank555 View Post
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.
Correct. Modifying it in initramfs would be even quicker, but a generic app can't do that. Also chmod to 0400, not 0600.
BLOG - G+(Chainfire) - G+(Personal) - TWITTER - IRC - DONATE

A proper quote includes only the relevant paragraphs, and a proper post never ends with the word "why"

Android
HTC G1, Hero, One
Samsung i5800, i9000*2, P1000*2, P7100, i9100*2, N7000, P6800, i9300, N7100, i9505, N9005
Sony T LT30p, Z C6603
Nexus Galaxy*2, N7, N10, N7-2013

SuperSU, Mobile ODIN, TriangleAway, DSLR Controller, CF-Root, 500 Firepaper, OpenDelta, USB Host Diagnostics, ExynosAbuseAPK, Live dmesg+logcat, NoMoarPowah!, CF-Bench, Chainfire3D, CF.lumen, SGS2 SIM Unlocker, GingerBreakAPK, SuperPower, and more!

Windows Mobile 5/6
E-Mobile EM-ONE
HTC Wizard*2, Kaiser, Touch, Diamond, Pro, HD*2, Diamond 2, Pro 2*2, HD2*2
Samsung i780, i900*2, i8000*2, b7300, b7320, b7330, b7620*2, b6520

WMWifiRouter, KaiserTweak, FPUEnabler, WMLongLife, WMRegOptimizer, CFC+GUI, TF3D+v2 ports, Kaiser+Omnia2+Snapdragon 3D drivers, GfxBoost, and more!

Windows Phone 7
LG GW910

NOTICE: I do not respond to tech support questions through PM.

The Following User Says Thank You to Chainfire For This Useful Post: [ Click to Expand ]
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes