Attend XDA's Second Annual Developer Conference, XDA:DevCon 2014!
5,782,840 Members 40,596 Now Online
XDA Developers Android and Mobile Development Forum

[ROOT][SECURITY] Root exploit on Exynos

Tip us?
 
Entropy512
Old
#21  
Senior Recognized Developer
Thanks Meter 24,248
Posts: 13,224
Join Date: Aug 2007
Location: Owego, NY

 
DONATE TO ME
Quote:
Originally Posted by rsd2000 View Post
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
This is already the current implementation in CM10.1 - exynos-mem is 660 system.graphics

So you need to be running in the graphics group to use the exploit. 660 system.graphics will block the easiest routes to abuse, but it may be possible for an app with camera permissions to do the privilege escalation. Not sure.

That is why I'll be working on getting Andrei's patches integrated into the smdk4210 kernel tree tonight. I think I just need to port his mach-midas changes over to mach-u1. Also on CM, I need to port his mach-midas changes to mach-p4notepq

Andrei, can you clarify your comment about CONFIG_CMA_DMA? Are you saying the fix is neutered if that config isn't used? The way I read your post, it sounds like you're saying the fix won't work on Note2 or Note10.1 (Exynos devices with 2GB RAM)?

Quote:
Originally Posted by manveru0 View Post
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)
That's odd. 0600 should block shell users from exploiting - 660 won't as the shell user has graphics privileges.
*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 User Says Thank You to Entropy512 For This Useful Post: [ Click to Expand ]
 
AndreiLux
Old
(Last edited by AndreiLux; 17th December 2012 at 05:15 PM.)
#22  
AndreiLux's Avatar
Senior Member
Thanks Meter 13,622
Posts: 2,759
Join Date: Jul 2011

 
DONATE TO ME
Quote:
Originally Posted by Entropy512 View Post
Andrei, can you clarify your comment about CONFIG_CMA_DMA? Are you saying the fix is neutered if that config isn't used? The way I read your post, it sounds like you're saying the fix won't work on Note2 or Note10.1 (Exynos devices with 2GB RAM)?
I meant that the whole mmap function is neutered if that configuration isn't set; it will always return -EINVAL. Currently only the 1GB S3 has that option enabled and the CMA framework is used for the camera (until now, somebody will still have to test HDMI). I tested the patch as it is on an N2 and everything works as it should.

So recap:

CMA_DMA enabled: filters through all the memory blocks and only lets through s3c-fimc. (S3, likely needed on the 4210 devices too)
CMA_DMA disabled: blocks everything, makes the device driver basically useless. (Currently all the 2GB devices)

The fix can actually just be just condensed to two lines checking the hard-coded memory addresses of the fimc device and denying access if it doesn't match, but I guess like this it's more dynamic to the other spaces in case they might be needed. I like to over-engineer (and I also think Samsung will expand the CMA-DMA framework for more device drivers in the future).
The Following 4 Users Say Thank You to AndreiLux For This Useful Post: [ Click to Expand ]
 
Entropy512
Old
#23  
Senior Recognized Developer
Thanks Meter 24,248
Posts: 13,224
Join Date: Aug 2007
Location: Owego, NY

 
DONATE TO ME
Quote:
Originally Posted by AndreiLux View Post
I meant that the whole mmap function is neutered if that configuration isn't set; it will always return -EINVAL. Currently only the 1GB S3 has that option enabled and the CMA framework is used for the camera (until now, somebody will still have to test HDMI). I tested the patch as it is on an N2 and everything works as it should.

So recap:

CMA_DMA enabled: filters through all the memory blocks and only lets through s3c-fimc. (S3, likely needed on the 4210 devices too)
CMA_DMA disabled: blocks everything, makes the device driver basically useless. (Currently all the 2GB devices)

The fix can actually just be just condensed to two lines checking the hard-coded memory addresses of the fimc device and denying access if it doesn't match, but I guess like this it's more dynamic to the other spaces in case they might be needed. I like to over-engineer (and I also think Samsung will expand the CMA-DMA framework for more device drivers in the future).
OK, thanks for the clarification.

Interesting, I wonder how N80xx libcamera sets up FIMC then. This might be useful in getting opensource gralloc/HWC working better on CM10.1, your discovery tells me there's some way to use FIMC without having the reserved FIMC regions... hmm...

Insignal's reference source relies heavily on multiple FIMC memory regions. Mobile's less so - gralloc never uses/provides FIMC memory itself, but camera use a second FIMC engine (FIMC2 I think) as an abstraction layer for camera data. It sounds like Mobile's newest implementations use the FIMC engine without any need for FIMC reserved memory, or at least not without any need of mapping it via exynos-mem.
*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
 
Entropy512
Old
(Last edited by Entropy512; 18th December 2012 at 02:55 AM.)
#24  
Senior Recognized Developer
Thanks Meter 24,248
Posts: 13,224
Join Date: Aug 2007
Location: Owego, NY

 
DONATE TO ME
Quote:
Originally Posted by qazibasit View Post
Well it was us who in the initial days were happy about samsung phone, which can easily be rooted and easy to develop on. But now these are the consequences....

Thanks dev for the effort. Samsung is still silent and our OTA JB is once again late. It will again go in trials because of this issue.

Sent from my GT-N7000 using xda app-developers app
Well, Samsungs have always been easily rootable *in a safe manner without exploits that make the system vulnerable to blackhats*. Rooting via flashing a system image in Odin pretty much can't be abused except if your device's physical security is compromised (someone grabs your device, flashes ??? to it, and returns it, a fairly unlikely attack scenario).

Quote:
Originally Posted by Yank555 View Post
Hi,

I can confirm, restricting fileaccess to exynos-mem, while it will brake the camera on a 4.1.2 Samsung ROM, if you flash the old "/system/lib/hw/camera.smdk4x12.so" (4.1.1) the camera will work again (on Samsung Update 6 based kernel at least that is).

I can break the camera by flashing the 4.1.2 lib and make the camera work again by flashing the 4.1.1 lib, back and forth.

Looks like the old lib doesn't use exynos-mem...

BTW, the fileacces I use for exynos-mem is the one Chainfire suggested (r--------).

JP.
Doesn't surprise me... Samsung has changed their graphics architecture significantly (especially in terms of memory usage/allocation) at least 3-4 times in the past year (as evidenced by the wildly different reports of whether certain permissions changes break camera or not). Only one of those variations (that in new/old Insignal source and Hardkernel source) is documented, and that's so ancient that it predates any Samsung Mobile firmware release that ever shipped to users as far as I can tell.

I've backported Andrei's patch to Exynos 4210. It seems to be working:
Code:
shell@android:/data/local/tmp $ ./exynos-abuse                                 
[!] Error mmap: Invalid argument|40067121
1|shell@android:/data/local/tmp $
This previously succeeded.

Camera seems to be as working as it was before - photos and video still work. hwaccel video decode also works other than Netflix, but Netflix was busted to begin with.

Patch is now under Gerrit review at: http://review.cyanogenmod.org/#/c/28568/
*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 12 Users Say Thank You to Entropy512 For This Useful Post: [ Click to Expand ]
 
pongster
Old
#25  
pongster's Avatar
Recognized Developer
Thanks Meter 5,935
Posts: 7,081
Join Date: Apr 2005
Location: Quezon City

 
DONATE TO ME
On an N7100 4.1.2 ROM , I have observed that using Andrei's patch causes the camera to fail and not even show the green screen.

Changing permissions to 0400 or 0600 for /dev/exynos-mem stops the exploit, as posted by the OP, from gaining a root shell. However, these 2 permissions break the rear camera and give me a green screen on 4.1.2.

Setting the permissions to 0606 or rw for others is the only way I can get camera working on 4.1.2.

What workaround would allow me to have camera working while stopping the exploit from potentially causing any damage? I can use Chainfire's app (and let users toggle it for camera to work when they need it) but it could get cumbersome for users.

Using an older 4.1.1 camera .so might work as some have confirmed, so does that mean we need Samsung to update/revert to use a camera .so that doesn't need /dev/exynos-mem to have others with rw access so that restricting permissions on it fixes the exploit and gets camera working on 4.1.2 Samsung Stock ROM's?
Check out the Insanely Fast, Uber Smooth, Exceptionally Stable Firmware & Kernels Built by the HyperDroid Dev Team...Get the latest updates... Click to Follow me on Twitter! Like our page on Facebook!

If you're enjoying the work we share with you please Press the THANKS button and RATE the thread... its FREE!


 
Yank555
Old
(Last edited by Yank555; 18th December 2012 at 08:45 AM.) Reason: Added link to flashable zip's with 4.1.1 and 4.1.2 camera lib
#26  
Yank555's Avatar
Senior Member
Thanks Meter 9,900
Posts: 6,216
Join Date: Sep 2009
Quote:
Originally Posted by pongster View Post
On an N7100 4.1.2 ROM , I have observed that using Andrei's patch causes the camera to fail and not even show the green screen.

Changing permissions to 0400 or 0600 for /dev/exynos-mem stops the exploit, as posted by the OP, from gaining a root shell. However, these 2 permissions break the rear camera and give me a green screen on 4.1.2.

Setting the permissions to 0606 or rw for others is the only way I can get camera working on 4.1.2.

What workaround would allow me to have camera working while stopping the exploit from potentially causing any damage? I can use Chainfire's app (and let users toggle it for camera to work when they need it) but it could get cumbersome for users.

Using an older 4.1.1 camera .so might work as some have confirmed, so does that mean we need Samsung to update/revert to use a camera .so that doesn't need /dev/exynos-mem to have others with rw access so that restricting permissions on it fixes the exploit and gets camera working on 4.1.2 Samsung Stock ROM's?
Using the 4.1.1 camera .so (1 file) is all that is required on a 4.1.2 ROM to make camera work even if fileaccess to eynos-mem is 400 (on i9300 at least). Everything linked works, too, video recording, best face etc.

JP.

PS : I posted the libs here.

Sent from my custom Paranoid Android 2.54 / Yank555.lu CM10 kernel v1.3d Aroma (Linux 3.0.57) powered Galaxy S3 i9300 using Tapatalk 2
Nexus 5 32Gb
SlimKAT 7.0 (official) / CWM / 768Mb zSwap
Yank555.lu kernel v1.0-alpha5

OnePlus One 64Gb
Faulty device, waiting on customer service to reply... since July 27th...


Note 3 SM-N9005 32Gb Proudly eFused
64Gb FAT32 / ROMs change / KK bootloader / CWM
Kenrel change

SGS3 I9300 32Gb
HTC Sensation XE
HTC HD2
TF300TG 32Gb


Credits FAdrums !
Kernels available in my Forum !
The Following 2 Users Say Thank You to Yank555 For This Useful Post: [ Click to Expand ]
 
Entropy512
Old
(Last edited by Entropy512; 18th December 2012 at 06:03 PM.)
#27  
Senior Recognized Developer
Thanks Meter 24,248
Posts: 13,224
Join Date: Aug 2007
Location: Owego, NY

 
DONATE TO ME
Quote:
Originally Posted by pongster View Post
I agree. It is a quick, lazy and stupid fix. Changing perms to 0400 and replacing the .so is more of a workaround since I need to record videos of my kids during their Christmas program tomorrow. It was better than having to change the permissions back when I want to use the camera... but far from the low level fix you've implemented.
I'm confused... Since you maintain your own kernel, why not just pull in Andrei's patch?

Edit: Ooops, missed one of your posts. I'm guessing you need to make an alteration to your patch to do the cma_add_region_descriptor calls in specific locations. The 4210 patch might be of use to you - on 4210, mach-u1 contained a duplicate of the reserve_mem.c implementation for CMA stuff. I'm guessing the issues you encountered will also affect N80xx, which I plan on looking at tonight.
*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 User Says Thank You to Entropy512 For This Useful Post: [ Click to Expand ]
 
AndreiLux
Old
(Last edited by AndreiLux; 18th December 2012 at 07:20 PM.)
#28  
AndreiLux's Avatar
Senior Member
Thanks Meter 13,622
Posts: 2,759
Join Date: Jul 2011

 
DONATE TO ME
Quote:
Originally Posted by Entropy512 View Post
I'm confused... Since you maintain your own kernel, why not just pull in Andrei's patch?

Edit: Ooops, missed one of your posts. I'm guessing you need to make an alteration to your patch to do the cma_add_region_descriptor calls in specific locations. The 4210 patch might be of use to you - on 4210, mach-u1 contained a duplicate of the reserve_mem.c implementation for CMA stuff. I'm guessing the issues you encountered will also affect N80xx, which I plan on looking at tonight.
The N7100 doesn't have CMA_DMA active in the defconfig, so I was probably wrong in the assumption that it is a kernel side condition, and 4.1.2 libraries directly access the fimc block regardless of that option. If that's the case then the fix is to just remove that check. I'll test it out and report back soon enough. All the N2 variants use mach-midas.c as their device file since it's the same hardware platform as the S3.

Edit: Here's a follow-up commit with that variation of the camera libraries: https://github.com/AndreiLux/Perseus...4e42c791f0813e

Code:
<6>[ 916.697437] c0 [exynos_mem_mmap] requesting access to (0x65c00000)-(0x661ef000)
 <6>[ 916.697489] c0 [exynos_mem_mmap] Checking space paddr(0x70000000)-(0x70bcc000) from 'fimc_is'
 <6>[ 916.697538] c0 [exynos_mem_mmap] Checking space paddr(0x6f800000)-(0x70000000) from 'fimd'
 <6>[ 916.697584] c0 [exynos_mem_mmap] Checking space paddr(0x6bb00000)-(0x6f800000) from 'fimc0'
 <6>[ 916.697631] c0 [exynos_mem_mmap] Checking space paddr(0x70ef4000)-(0x70ff4000) from 'srp'
 <6>[ 916.697679] c0 [exynos_mem_mmap] Checking space paddr(0x65c00000)-(0x66b00000) from 'fimc1'
 <6>[ 916.697730] c0 [exynos_mem_mmap] Accessing space 0x65c00000/0x00f00000 for 'fimc1'
 <6>[ 916.697866] c0 [exynos_mem_mmap] Checking space paddr(0x64000000)-(0x64400000) from 'mfc-normal'
 <6>[ 916.697963] c0 [exynos_mem_mmap] Checking space paddr(0x5c000000)-(0x5c100000) from 'sectbl'
 <6>[ 916.698008] c0 [exynos_mem_mmap] Checking space paddr(0x5c100000)-(0x5f200000) from 'mfc-secure'
 <6>[ 916.698054] c0 [exynos_mem_mmap] Checking space paddr(0x5f200000)-(0x63800000) from 'ion'
 <7>[ 916.698306] c0 [exynos_mem_mmap_open] addr(0x45b0f000)
The Following 5 Users Say Thank You to AndreiLux For This Useful Post: [ Click to Expand ]
 
Chainfire
Old
#29  
Chainfire's Avatar
Senior Moderator / Senior Recognized Developer - Where is my shirt?
Thanks Meter 49,382
Posts: 9,017
Join Date: Oct 2007

 
DONATE TO ME
In case anybody cares, I've posted an in-depth article regarding the app-based patches here: Why Exynos exploit patches may not work as expected + demo app
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
LG G Pad 8.3, G Watch, G3
Moto E
Samsung i5800, i9000*2, P1000*2, P7100, i9100*2, N7000, P6800, i9300, N7100, i9505, N9005, G900F
Sony T LT30p, Z C6603
Nexus Galaxy*2, N7*2, N10, N7-2013, N7-2013-3G, N5

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 19 Users Say Thank You to Chainfire For This Useful Post: [ Click to Expand ]
 
garyd9
Old
(Last edited by garyd9; 20th December 2012 at 09:17 PM.)
#30  
garyd9's Avatar
Recognized Developer
Thanks Meter 1,979
Posts: 1,951
Join Date: Sep 2006
Location: Pittsburgh, PA
I've copied this thread to: http://forum.xda-developers.com/show....php?t=2057818. Please use that link for anything that doesn't follow the guidelines of this section (as seen here: http://forum.xda-developers.com/show....php?t=2017367.)

To keep in simple, if its not technical development talk about the process of the defect or the resolution, please post here: http://forum.xda-developers.com/show....php?t=2057818

If you want to discuss a specific resolution from a user perspective, please post here: http://forum.xda-developers.com/show....php?t=2057818

If you want to say thanks, please post here: http://forum.xda-developers.com/show....php?t=2057818

If you want to debate Samsung, please post here: http://forum.xda-developers.com/show....php?t=2057818

If you want to compare different approaches to work around the defect, please post here: http://forum.xda-developers.com/show....php?t=2057818

If you don't want to deal with me deleting your posts anymore, please post here: http://forum.xda-developers.com/show....php?t=2057818

If I've deleted your post from THIS thread and you feel it DOES meet the guidelines of the section, feel free to send me a PM with information to help me find your post and I'll re-evaluate it.

Again, for further general discussion on this topic, please use the following thread: http://forum.xda-developers.com/show....php?t=2057818

This thread will follow the guidelines of this section (and all other posts will be deleted.)

Closed for cleaning.

Donations: I don't accept donations, but if you are feeling charitable, help a child by going to http://www.shrinershospitalsforchildren.org/
and click the "Donate Now" link at the top.

The Following 4 Users Say Thank You to garyd9 For This Useful Post: [ Click to Expand ]
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes