[ROOT][SECURITY] Root exploit on Exynos

Search This thread

Entropy512

Senior Recognized Developer
Aug 31, 2007
14,088
25,086
Owego, NY
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)?

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.
 
  • Like
Reactions: nikhilguitar

AndreiLux

Senior Member
Jul 9, 2011
3,209
14,598
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).
 
Last edited:

Entropy512

Senior Recognized Developer
Aug 31, 2007
14,088
25,086
Owego, NY
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.
 

Entropy512

Senior Recognized Developer
Aug 31, 2007
14,088
25,086
Owego, NY
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).

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/
 
Last edited:

pongster

Retired Recognized Developer
Apr 15, 2005
7,059
5,861
Quezon City
www.facebook.com
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?
 

Yank555

Senior Member
Sep 18, 2009
8,713
19,939
Sony Xperia Pro-I
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
 
Last edited:

Entropy512

Senior Recognized Developer
Aug 31, 2007
14,088
25,086
Owego, NY
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.
 
Last edited:
  • Like
Reactions: pongster

AndreiLux

Senior Member
Jul 9, 2011
3,209
14,598
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-S3/commit/81c95f6046880be48ef377ebae4e42c791f0813e

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'
[B][COLOR="Red"] <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'[/COLOR][/B]
 <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)
 
Last edited:

garyd9

Inactive Recognized Developer
Sep 13, 2006
2,643
2,732
53
Pittsburgh, PA
I've copied this thread to: http://xdaforums.com/showthread.php?t=2057818. Please use that link for anything that doesn't follow the guidelines of this section (as seen here: http://xdaforums.com/showthread.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://xdaforums.com/showthread.php?t=2057818

If you want to discuss a specific resolution from a user perspective, please post here: http://xdaforums.com/showthread.php?t=2057818

If you want to say thanks, please post here: http://xdaforums.com/showthread.php?t=2057818

If you want to debate Samsung, please post here: http://xdaforums.com/showthread.php?t=2057818

If you want to compare different approaches to work around the defect, please post here: http://xdaforums.com/showthread.php?t=2057818

If you don't want to deal with me deleting your posts anymore, please post here: http://xdaforums.com/showthread.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://xdaforums.com/showthread.php?t=2057818

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

Closed for cleaning.
 
Last edited:

AndreiLux

Senior Member
Jul 9, 2011
3,209
14,598
Samsung has released the kernel sources with their approach, i9300 update 7.

It is basically this:
http://review.cyanogenmod.org/#/c/29910/


Their approach is very similar to AndreiLuxs, but they have also patched the other attack vectors such as s3c-mem, fimg/fimc.

Verified that the original exynos-abuse indeed does not work with this approach.
That commit contains way too much, some are CMA stuff unrelated to the security fix.

I extracted the fixes properly and they're in my repo, check it out. And yes the secmem patch is also needed (s5p-smem, also fixed that back in December but we kept it undisclosed, although my commit was public). https://github.com/AndreiLux/Perseus-S3

I'm having some inconsistency on their fimc checks though with video decoding on higher resolutions causing size accesses to exceed the cma limits on the MFC block on some frames. I #if 0'ed that part until I find out what causes it. So watch out with that.
 
Last edited:

alephzain

Senior Member
Sep 29, 2010
117
2,822
That commit contains way too much, some are CMA stuff unrelated to the security fix.

I extracted the fixes properly and they're in my repo, check it out. And yes the secmem patch is also needed (s5p-smem, also fixed that back in December but we kept it undisclosed, although my commit was public). https://github.com/AndreiLux/Perseus-S3

I'm having some inconsistency on their fimc checks though with video decoding on higher resolutions causing size accesses to exceed the cma limits on the MFC block on some frames. I #if 0'ed that part until I find out what causes it. So watch out with that.

Thanks Andrei for the diff patch.
Samsung took finally a paranoid approach by adding check multiple with cma_is_registered_region.
Some possible attack vectors via devices have been patched :
  • s3c-mem (possible exploitation with ioctl and only accessible to root on stock rom)
  • fimg2d (not investigate)
  • s5p-smem (no need to explain ;))

Just want to highlight the paranoid approach of Samsung which add check protections in kernel to avoid misuses of permissions on this devices on alternative roms.
 

Phylu

Member
Oct 18, 2008
6
1
Munich
License of Exynose-abuse

Thanks a lot for the good work with this exploit.

I am currently doing my bachelor thesis about Android Security and would like to use your exploit within some code I am writing. Unfortunately, I could not find a license within the source code.

If I may use your code that would be great. May I do so?

Best regards
Phylu
 

alephzain

Senior Member
Sep 29, 2010
117
2,822
Thanks a lot for the good work with this exploit.

I am currently doing my bachelor thesis about Android Security and would like to use your exploit within some code I am writing. Unfortunately, I could not find a license within the source code.

If I may use your code that would be great. May I do so?

Best regards
Phylu

Yes of course, you can consider code under GPL license
 

hartlezzevolved

Senior Member
Nov 6, 2013
67
1
Bacoor City
Very interesting. Thanks for bringing that up. (Have also flagged some Samsung engineers to read this)

Also, I'm building an APK for this to make it easy.

EDIT: APK posted here: http://xdaforums.com/showthread.php?t=2050297, download, install, run, and your device is rooted with SuperSU.

EDIT#2: This app now also lets you disable the exploit :)

Hi Chainfire..

Will this app work on other device ? Or only Samsung Firmwares? Thanks :)
 

Top Liked Posts

  • There are no posts matching your filters.
  • 290
    EDIT: For general discussion about this topic, please post in the following location (and not here): http://xdaforums.com/showthread.php?t=2057818

    Now find a one-click root application at http://xdaforums.com/showthread.php?t=2130276. More exploits coming.

    Hi,

    Recently discover a way to obtain root on S3 without ODIN flashing.
    The security hole is in kernel, exactly with the device /dev/exynos-mem.
    This device is R/W by all users and give access to all physical memory :confused: ... what's wrong with Samsung ?
    Its like /dev/mem but for all.
    Three libraries seems to use /dev/exynos-mem:
    • /system/lib/hw/camera.smdk4x12.so
    • /system/lib/hw/gralloc.smdk4x12.so
    • /system/lib/libhdmi.so

    Many devices are concerned :
    • Samsung Galaxy S2
    • Samsung Galxy Note 2
    • MEIZU MX
    • potentialy all devices who embed exynos processor (4210 and 4412) which use Samsung kernel sources.
    The good news is we can easily obtain root on these devices and the bad is there is no control over it.

    Ram dump, kernel code injection and others could be possible via app installation from Play Store. It certainly exists many ways
    to do that but Samsung give an easy way to exploit. This security hole is dangerous and expose phone to malicious apps.
    Exploitation with native C and JNI could be easily feasible.

    Edited
    Some details :
    /dev/exynos-mem seems to be used for graphic usage like camera, graphic memory allocation, hdmi.
    By activating pid display in kmsg, surfaceflinger do mmap on the device (via one of the three shared libraries above ?? I have not see reference in binary to these libraires)

    The operations allowed on the device are (from linux/drivers/char/mem.c) :
    Code:
    static const struct file_operations exynos_mem_fops = {
        .open       = exynos_mem_open,
        .release    = exynos_mem_release,
        .unlocked_ioctl = exynos_mem_ioctl,
        .mmap       = exynos_mem_mmap,
    }

    and the default permissions (from linux/drivers/char/mem.c) :
    Code:
    #ifdef CONFIG_EXYNOS_MEM
        [14] = {"exynos-mem", S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH
                | S_IWOTH, &exynos_mem_fops},
    #endif

    ioctl request on /dev/exynos-mem permit to clean / flush L1 and L2 cache, set non cacheable page memory and set physical memory address for use with mmap.
    Now the interesting part : mmap operation.
    The only limit is to restrict access to lowmem (from linux/drivers/char/exynos-mem.c) :
    Code:
    /* TODO: currently lowmem is only avaiable */
    if ((phys_to_virt(start) < (void *)PAGE_OFFSET) ||
        (phys_to_virt(start) >= high_memory)) {
        pr_err("[%s] invalid paddr(0x%08x)\n", __func__, start);
        return -EINVAL;
    }
    The comment in above code could be frightening.

    And an eye in Documentation/arm/memory.txt say :
    Code:
    Start       End             Use
    --------------------------------------------------------------------------
    PAGE_OFFSET high_memory-1   Kernel direct-mapped RAM region.
                                This maps the platforms RAM, and typically
                                maps all platform RAM in a 1:1 relationship.

    In other words, this device only permit to own the physical memory including kernel code.
    The question is why permissions are set to read/write for all in kernel AND in ueventd.smdk4x12.rc:
    • samsung developper in charge of this would lose his job
    • some samsung apps with basic rights need to access it (I doubt it)
    • a huge mistake
    A simple patch could be to set permissions to 0660 or 0600 in ueventd.smdk4x12.rc, but I don't know how it would affect samsung applications/services.

    In attachment, binary and source to obtain for root shell.
    137
    Very interesting. Thanks for bringing that up. (Have also flagged some Samsung engineers to read this)

    Also, I'm building an APK for this to make it easy.

    EDIT: APK posted here: http://xdaforums.com/showthread.php?t=2050297, download, install, run, and your device is rooted with SuperSU.

    EDIT#2: This app now also lets you disable the exploit :)
    106
    Sooooo....

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

    Source @ https://github.com/AndreiLux/Perseus-S3/commit/fb36195dab87e002721c7d1a8294a400c6b40a71
    Edit: Follow-up commit for Note 2 (Possibly N8000 too) users @ https://github.com/AndreiLux/Perseus-S3/commit/81c95f6046880be48ef377ebae4e42c791f0813e

    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.
    51
    Removing either read or write permissions will kill the camera. I didn't see any other deterioration in anything else.

    rElVQl.png


    My guess the best fix would be to limit the access to the DMA memory spaces which this thing actually needs, the definition of the different CMA areas are in /arch/arm/mach-exynos/mach-midas.c for the S3 and N2.

    Front camera for example:
    Code:
    #ifndef CONFIG_USE_FIMC_CMA
    		{
    			.name = "fimc1",
    			.size = CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC1 * SZ_1K,
    #if defined(CONFIG_MACH_GC1)
    			.start = 0x5ec00000,
    #else
    			.start = 0x65c00000,
    #endif
    		},
    #endif

    Generally all memory areas allocated through s5p_cma_region_reserve in /arch/arm/plat-s5p/reserve_mem.c would be treated as exceptions and everything else needs to be blocked.

    Update: Low-level kernel fix for developers posted here.

    A kernel based fix as I posted above is the only method to fix the security hole while also not breaking the camera. In all other cases if you are not able or willing to flash a kernel, use Chainfire's application.
    26
    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://xdaforums.com/showthread.php?t=2050297