FORUMS
Remove All Ads from XDA
Post Reply Email Thread
EDIT: For general discussion about this topic, please post in the following location (and not here): http://forum.xda-developers.com/show....php?t=2057818

Now find a one-click root application at http://forum.xda-developers.com/show....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 ... 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.
Attached Files
File Type: gz exynos-abuse.tar.gz - [Click for QR Code] (18.0 KB, 41425 views)
The Following 291 Users Say Thank You to alephzain For This Useful Post: [ View ] Gift alephzain Ad-Free
17th December 2012, 11:53 AM |#2  
Yank555's Avatar
Senior Member
Thanks Meter: 20,162
 
More
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 2 Users Say Thank You to Yank555 For This Useful Post: [ View ] Gift Yank555 Ad-Free
17th December 2012, 11:56 AM |#3  
Chainfire's Avatar
Senior Moderator / Senior Recognized Developer - Where is my shirt?
Thanks Meter: 86,611
 
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 2 Users Say Thank You to Chainfire For This Useful Post: [ View ]
17th December 2012, 04:53 PM |#4  
AndreiLux's Avatar
Senior Member
Thanks Meter: 14,705
 
Donate to Me
More
Quote:
Originally Posted by Entropy512

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: [ View ] Gift AndreiLux Ad-Free
17th December 2012, 06:12 PM |#5  
Senior Recognized Developer
Flag Owego, NY
Thanks Meter: 25,472
 
Donate to Me
More
Quote:
Originally Posted by AndreiLux

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.
18th December 2012, 05:32 AM |#6  
pongster's Avatar
Retired Recognized Developer
Flag Quezon City
Thanks Meter: 5,940
 
Donate to Me
More
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?
18th December 2012, 06:24 AM |#7  
Yank555's Avatar
Senior Member
Thanks Meter: 20,162
 
More
Quote:
Originally Posted by pongster

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
The Following 2 Users Say Thank You to Yank555 For This Useful Post: [ View ] Gift Yank555 Ad-Free
9th January 2013, 07:10 AM |#8  
AndreiLux's Avatar
Senior Member
Thanks Meter: 14,705
 
Donate to Me
More
Quote:
Originally Posted by espenfjo

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.
The Following 5 Users Say Thank You to AndreiLux For This Useful Post: [ View ] Gift AndreiLux Ad-Free
9th January 2013, 09:06 AM |#9  
alephzain's Avatar
OP Senior Member
Thanks Meter: 2,728
 
Donate to Me
More
Quote:
Originally Posted by AndreiLux

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.
The Following 6 Users Say Thank You to alephzain For This Useful Post: [ View ] Gift alephzain Ad-Free
8th February 2013, 06:50 PM |#10  
alephzain's Avatar
OP Senior Member
Thanks Meter: 2,728
 
Donate to Me
More
Related to the work here and other stuff you will find a one-click root application here : http://forum.xda-developers.com/show....php?t=2130276.

Its a root framework including current exploit + an exploit for omap devices and soon other exploits.
The Following 3 Users Say Thank You to alephzain For This Useful Post: [ View ] Gift alephzain Ad-Free
Post Reply Subscribe to Thread
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes