Welcome to XDA

Search to go directly to your device's forum

Register an account

Unlock full posting privileges

Ask a question

No registration required
Post Reply

[ROOT][SECURITY] Root exploit on Exynos

OP alephzain

16th December 2012, 11:28 PM   |  #11  
Senior Recognized Developer
Flag Owego, NY
Thanks Meter: 24,855
 
13,541 posts
Join Date:Joined: Aug 2007
Donate to Me
More
Quote:
Originally Posted by supercurio

Because your shell is in graphics group.

I was beginning to suspect that, thanks for confirming.

Quote:
Originally Posted by dennis.l

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.
The Following 3 Users Say Thank You to Entropy512 For This Useful Post: [ View ]
17th December 2012, 12:09 AM   |  #12  
supercurio's Avatar
Senior Recognized Developer
Flag Chambéry
Thanks Meter: 5,072
 
3,529 posts
Join Date:Joined: May 2010
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?
17th December 2012, 02:33 AM   |  #13  
Chainfire's Avatar
Senior Moderator / Senior Recognized Developer - Where is my shirt?
Thanks Meter: 55,805
 
9,487 posts
Join Date:Joined: Oct 2007
Donate to Me
More
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
The Following 25 Users Say Thank You to Chainfire For This Useful Post: [ View ]
17th December 2012, 02:46 AM   |  #14  
supercurio's Avatar
Senior Recognized Developer
Flag Chambéry
Thanks Meter: 5,072
 
3,529 posts
Join Date:Joined: May 2010
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
Last edited by garyd9; 17th December 2012 at 03:16 PM. Reason: link to XDA thread for the specific solution
The Following 18 Users Say Thank You to supercurio For This Useful Post: [ View ]
17th December 2012, 06:24 AM   |  #15  
Senior Member
Flag JHB
Thanks Meter: 743
 
2,021 posts
Join Date:Joined: Jan 2006
Quote:
Originally Posted by RyanZA

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.
The Following User Says Thank You to RyanZA For This Useful Post: [ View ]
17th December 2012, 06:44 AM   |  #16  
AndreiLux's Avatar
Senior Member
Thanks Meter: 14,119
 
2,956 posts
Join Date:Joined: 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.
Last edited by AndreiLux; 18th December 2012 at 09:11 PM.
The Following 105 Users Say Thank You to AndreiLux For This Useful Post: [ View ]
17th December 2012, 10:39 AM   |  #17  
Member
Thanks Meter: 2
 
47 posts
Join Date:Joined: Jun 2011
Quote:
Originally Posted by Chainfire

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

Quote:
Originally Posted by supercurio

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?
Last edited by julandroid; 17th December 2012 at 10:42 AM.
17th December 2012, 11:15 AM   |  #18  
Chainfire's Avatar
Senior Moderator / Senior Recognized Developer - Where is my shirt?
Thanks Meter: 55,805
 
9,487 posts
Join Date:Joined: Oct 2007
Donate to Me
More
Quote:
Originally Posted by julandroid

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.
Last edited by Chainfire; 17th December 2012 at 03:11 PM.
The Following 20 Users Say Thank You to Chainfire For This Useful Post: [ View ]
17th December 2012, 12:53 PM   |  #19  
Yank555's Avatar
Senior Member
Thanks Meter: 10,471
 
6,362 posts
Join Date:Joined: Sep 2009
Quote:
Originally Posted by Chainfire

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
The Following User Says Thank You to Yank555 For This Useful Post: [ View ]
17th December 2012, 12:56 PM   |  #20  
Chainfire's Avatar
Senior Moderator / Senior Recognized Developer - Where is my shirt?
Thanks Meter: 55,805
 
9,487 posts
Join Date:Joined: Oct 2007
Donate to Me
More
Quote:
Originally Posted by Yank555

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.

The Following User Says Thank You to Chainfire For This Useful Post: [ View ]
Post Reply Subscribe to Thread
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes