[ROOT][SECURITY] Root exploit on Exynos

Search This thread

alephzain

Senior Member
Sep 29, 2010
117
2,822
Mod edit: This thread is a copy of a thread originally posted in the "development discussion" section. General posts should be made in this thread (and not in the original.) Only posts which follow the guidelines of the Development Discussion section should be made in the original thread (located here: http://xdaforums.com/showthread.php?t=2048511)

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.
 

Attachments

  • exynos-abuse.tar.gz
    18 KB · Views: 3,953
Last edited:

AndreiLux

Senior Member
Jul 9, 2011
3,209
14,598
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.
 
  • Like
Reactions: longnh86

Chainfire

Moderator Emeritus / Senior Recognized Developer
Oct 2, 2007
11,452
87,862
www.chainfire.eu
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 :)
 

supercurio

Retired Senior Recognized Developer
May 31, 2010
3,550
5,041
Chambéry
spectrastudy.com
Okay thanks, I confirm that people at Samsung have just made aware of it.

I also suggested to open an easy way to contact their security team, possibly with reward so such vulnerability (as cool as dangerous) would be reported to them instead of published on XDA as-is next time.

@alephzain, did you tried to report it to people able to fix this serious security issue before publishing it here?
 

thebobp

Senior Member
Feb 16, 2012
1,189
203
I'm guessing no, considering /dev/exynos-mem (why would they do that?) but does any similar vulnerability exist for the Qualcomm S3?
 

Entropy512

Senior Recognized Developer
Aug 31, 2007
14,088
25,086
Owego, NY
Okay thanks, I confirm that people at Samsung have just made aware of it.

I also suggested to open an easy way to contact their security team, possibly with reward so such vulnerability (as cool as dangerous) would be reported to them instead of published on XDA as-is next time.

@alephzain, did you tried to report it to people able to fix this serious security issue before publishing it here?

That was suggested to them months ago in the aftermath of the Superbrick disaster. It was completely rejected within days.

It'll never happen.

Looks like Superbrick is no longer just "an open source problem" (Samsung's attitude regarding it) - Samsung devices vulnerable to Superbrick have been one non-local (as in does not require USB) root exploit away from market apps being able to do permanent unrecoverable damage to devices. Samsung has not cared about that fact and allowed Superbrick to remain unfixed for months, even though they've had the patch since before early September and device updates have gone out since then (Sprint FI27 was built on September 27, 3 weeks after the patch had even been merged to mainline Linux, and 4-5 weeks since they first authored it.)

Now there's a remote exploit and there is zero protection against malware causing permanent damage to a device.
 

jcase

Retired Forum Mod / Senior Recognized Developer
Feb 20, 2010
6,308
15,761
Raleigh NC
That was suggested to them months ago in the aftermath of the Superbrick disaster. It was completely rejected within days.


[Edit: to OP, NICE FIND!]


It'll never happen.

Looks like Superbrick is no longer just "an open source problem" - Samsung devices vulnerable to Superbrick have been one non-local (as in does not require USB) root exploit away from market apps being able to do permanent unrecoverable damage to devices. Samsung has not cared about that fact and allowed Superbrick to remain unfixed for months, even though they've had the patch since before early September and device updates have gone out since then (Sprint FI27 was built on September 27, 3 weeks after the patch had even been merged to mainline Linux, and 4-5 weeks since they first authored it.)

Now there's a remote exploit and there is zero protection against malware causing permanent damage to a device.

Please explain how this is a remote exploit? This looks entirely local to me. Vulns happen, every vendor gets hit with them. Google does, Apple does Motorola does, HTC does, LG does, Samsung does, ASUS does, Nvidia, Qualcomm etc etc, it is all part of the game. Hell go look at the recent qualcomm disclosures, almost every qualcomm since 2009, wide open! Sh*t happens. Any device with root on it, be it exploit or whatever is open to permanent damage from malicious, want to nuke an htc with root? dd if=/dev/zero of=/dev/block/mmcblk0p4. Pantech/LG/Mostqualcoms hit all the bootloaders. Hell system user is enough on LG phones, and most other brands to brick them.

I'm not sure about rewards, but I have reported vulns and bugs to every major vendor, and the only three who ever respond to me are Google, Samsung and Motorola. All three respond promptly and polite, and occasionally follow up if requested. Vendor not getting back to you? security@android.com is quite good at getting them to respond, just tell them the vendor is not responding. More than once they have gotten a dialog with a vendor opened with me.

Understanding update timelines is another issue, vendor updates generally have to go through development, QA at the vendor (sent back if major issues found), then in the case of Sprint and other carriers, sent to carrier QA (returned to OEM if major issues found) . Major changes to the radio? Yep off to the FCC as well! Updates can take considerable time. Not excusing the "superbrick" bug, just pointing out a few weeks (or in the case of sprint or Vernon a few months) can be expected. Want faster updates? Buy an international device, and get a GSM carrier.
 

supercurio

Retired Senior Recognized Developer
May 31, 2010
3,550
5,041
Chambéry
spectrastudy.com
That was suggested to them months ago in the aftermath of the Superbrick disaster. It was completely rejected within days.

It'll never happen.

Looks like Superbrick is no longer just "an open source problem" (Samsung's attitude regarding it) - Samsung devices vulnerable to Superbrick have been one non-local (as in does not require USB) root exploit away from market apps being able to do permanent unrecoverable damage to devices. Samsung has not cared about that fact and allowed Superbrick to remain unfixed for months, even though they've had the patch since before early September and device updates have gone out since then (Sprint FI27 was built on September 27, 3 weeks after the patch had even been merged to mainline Linux, and 4-5 weeks since they first authored it.)

Now there's a remote exploit and there is zero protection against malware causing permanent damage to a device.

I think we all got the point you're not happy with Samsung.

The issue discussed here is off topic.
Also I'm sorry to observe that your "It'll never happen" on security sounds more like bad-mouthing than an informed comment.

On a more technical aspect, as soon as you have root permissions there's a large choice of method allowing to hard-brick or damage hardware without relying on a bug present in some eMMC controllers that I won't of course describe here.
 

yugoport

Senior Member
Jul 3, 2009
969
330
Okay thanks, I confirm that people at Samsung have just made aware of it.

I also suggested to open an easy way to contact their security team, possibly with reward so such vulnerability (as cool as dangerous) would be reported to them instead of published on XDA as-is next time.

@alephzain, did you tried to report it to people able to fix this serious security issue before publishing it here?

In my point of view, we are a community of developers, not a bunch of people trying to help Sammy to solve the problems that their extremely well paid engineers can't see. .

I truly respect your point of view, and cheers to your sense of civism to try to protect the people that are using this phones and don't have ability and knowledge to protect themselves against a so severe lack of security, but seriously Sammy doesn't care about users or developers, they care about money. .So first I think he did well to post here and then inform Samsung.






That was suggested to them months ago in the aftermath of the Superbrick disaster. It was completely rejected within days.

It'll never happen.

Looks like Superbrick is no longer just "an open source problem" - Samsung devices vulnerable to Superbrick have been one non-local (as in does not require USB) root exploit away from market apps being able to do permanent unrecoverable damage to devices. Samsung has not cared about that fact and allowed Superbrick to remain unfixed for months, even though they've had the patch since before early September and device updates have gone out since then (Sprint FI27 was built on September 27, 3 weeks after the patch had even been merged to mainline Linux, and 4-5 weeks since they first authored it.)

Now there's a remote exploit and there is zero protection against malware causing permanent damage to a device.

Well pointed, for a discover like this they should pay a fortune to alephzain, and other devs that help fixing this security problems, but they just don't care. .

I'm sure they will fix it eventually in the next updates but they will encover it of course and will leave millions of users at risk until that. .they don't want this kind of publicity.


I hope that they give a good reward to our devs that everyday work to improve our devices. .but I know they will not do it. . But that's the fun of it isn't it?


Sent from my GT-I9300 using xda premium
 

supercurio

Retired Senior Recognized Developer
May 31, 2010
3,550
5,041
Chambéry
spectrastudy.com
@alephzain thanks for sharing the source code of the exploit: short, elegant, efficient, to me that's art :)

Your short documentation and clean writing style even made easier to learn from it.
 

supercurio

Retired Senior Recognized Developer
May 31, 2010
3,550
5,041
Chambéry
spectrastudy.com
In my point of view, we are a community of developers, not a bunch of people trying to help Sammy to solve the problems that their extremely well paid engineers can't see. .

I truly respect your point of view, and cheers to your sense of civism to try to protect the people that are using this phones and don't have ability and knowledge to protect themselves against a so severe lack of security, but seriously Sammy doesn't care about users or developers, they care about money. .So first I think he did well to post here and then inform Samsung.

This is not Samsung-specific in any way.
Fortunately most people discovering security flaws inform original authors so they can fix the issue and release updates before the exploit is publicly released.

I'm not judging alephzain here, because its possible he tried to report the issue but found no-one listening, taking him seriously, or simply couldn’t find who to contact, hence my question to him to know if he tried or just didn't care, also because I'm a fan of the technical exploit and use similar method in my apps as apps to do things not supposed to be done.

Millions of vulnerable devices are out there now. This exploit which is very well designed and I believe very hard to detect if carefully hidden inside an Android app.

It means privacy, security of a large amount of people and corporation is at a larger risk right now as the manufacturer didn't had the chance to provide a security fix to its users, because of not being aware of the issue.
 

julandroid

Senior Member
Jun 3, 2011
50
4
What a nuisance!

The most important question is - how to quickly patch this?

A simple chmod 0600 /dev/exynos-mem does not survive reboot.

Any ideas that does not envolve unpack/pack update images?
 

julandroid

Senior Member
Jun 3, 2011
50
4
I don't care about the app right now. That's why those reports *should* go directly to the root of the problem - Samsung. Because once they go to the surface everyone can exploit the device. Eventually, if someone decide to post the exploit first - then it should be prepared with the solution.

For know it will be a good idea, anyone with knowledge just to give idea what to do (manually). For example I don't have any ueventd.smdk4x12.rc (Galaxy S2, CM10). I guess I need to unpack boot.img, to find where permissions are set for /dev/exynos-mem, then to repack boot.img and flash it.
 

AndreiLux

Senior Member
Jul 9, 2011
3,209
14,598
I don't care about the app right now. That's why those reports *should* go directly to the root of the problem - Samsung. Because once they go to the surface everyone can exploit the device. Eventually, if someone decide to post the exploit first - then it should be prepared with the solution.

For know it will be a good idea, anyone with knowledge just to give idea what to do (manually). For example I don't have any ueventd.smdk4x12.rc (Galaxy S2, CM10). I guess I need to unpack boot.img, to find where permissions are set for /dev/exynos-mem, then to repack boot.img and flash it.
As far as I'm concerned I already implemented a fix into the kernel to just whitelist the FIMC0 memory space for the mmap function and to refuse access to the rest of lowmem. I'll post it later when I sorted some things with the other DMA spaces.
 

supercurio

Retired Senior Recognized Developer
May 31, 2010
3,550
5,041
Chambéry
spectrastudy.com
Okay I feel lazy this Sunday night but will still quickly write an app that fixes the vulnerability (simple chmod 660) at boot.
Just for the sake of it.

(Breaks camera on S III, not on Note II)
 

Top Liked Posts

  • There are no posts matching your filters.
  • 5
    Mod edit: This thread is a copy of a thread originally posted in the "development discussion" section. General posts should be made in this thread (and not in the original.) Only posts which follow the guidelines of the Development Discussion section should be made in the original thread (located here: http://xdaforums.com/showthread.php?t=2048511)

    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.
    3
    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 :)
    2
    please forgive me, but all this technical speak has lost me. can someone explain in plain english what this exploit makes vulnerable - does it mean apps can steal your personal data. please give simple examples.

    i appreciate the exploit gives access to physical memory. does this mean, for example, that passwords can be gained by malicious apps?
    No need! You got it! Though you potentially give rooted apps these same permissions, you know you're doing it. With this exploit, apps don't need the users permission or to give any sort of notification.

    Elite Tester for Mijjz Goodness
    sigpic4619062_2.gif
    1
    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.