FORUMS
Remove All Ads from XDA

[ROOT][SECURITY] Root exploit on Exynos

117 posts
Thanks Meter: 2,706
 
By alephzain, Senior Member on 15th December 2012, 10:56 AM
Post Reply Email Thread
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://forum.xda-developers.com/show....php?t=2048511)

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, 3558 views)
The Following 5 Users Say Thank You to alephzain For This Useful Post: [ View ] Gift alephzain Ad-Free
 
 
16th December 2012, 03:53 AM |#2  
AndreiLux's Avatar
Senior Member
Thanks Meter: 14,694
 
Donate to Me
More
Removing either read or write permissions will kill the camera. I didn't see any other deterioration in anything else.



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.
The Following User Says Thank You to AndreiLux For This Useful Post: [ View ] Gift AndreiLux Ad-Free
16th December 2012, 01:03 PM |#3  
Chainfire's Avatar
Senior Moderator / Senior Recognized Developer - Where is my shirt?
Thanks Meter: 86,134
 
Donate to Me
More
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://forum.xda-developers.com/show....php?t=2050297, download, install, run, and your device is rooted with SuperSU.

EDIT#2: This app now also lets you disable the exploit
The Following 3 Users Say Thank You to Chainfire For This Useful Post: [ View ]
16th December 2012, 02:45 PM |#4  
thegh0sts's Avatar
Senior Member
Flag Toronto
Thanks Meter: 128
 
More
would this trip the flash counter? my guess says no.
16th December 2012, 02:54 PM |#5  
supercurio's Avatar
Retired Senior Recognized Developer
Flag Chambéry
Thanks Meter: 5,095
 
Donate to Me
More
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?
16th December 2012, 03:34 PM |#6  
Member
Flag Karlsruhe
Thanks Meter: 7
 
More
I'm not very good with Linux, but I did
Code:
chmod 600 /dev/exynos-mem
on my GSII international with CM10 and the camera still works. Am I safe for now?
16th December 2012, 04:10 PM |#7  
Senior Member
Thanks Meter: 212
 
More
I'm guessing no, considering /dev/exynos-mem (why would they do that?) but does any similar vulnerability exist for the Qualcomm S3?
16th December 2012, 05:43 PM |#8  
garyd9's Avatar
Inactive Recognized Developer
Flag Pittsburgh, PA
Thanks Meter: 2,734
 
More
thread cleaned. "thanks", "nice", "oooh", "ahh" and remarks about code comments are off topic.

(If you want to discuss what is/isn't of topic, please reply go here: http://forum.xda-developers.com/show....php?t=2017367)
16th December 2012, 06:50 PM |#9  
Senior Recognized Developer
Flag Owego, NY
Thanks Meter: 25,474
 
Donate to Me
More
Quote:
Originally Posted by supercurio

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.
16th December 2012, 07:07 PM |#10  
jcase's Avatar
Forum Moderator / Senior Recognized Developer - Taco Vendor
Flag Sequim WA
Thanks Meter: 15,608
 
10
Donate to Me
More
Quote:
Originally Posted by Entropy512

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.
16th December 2012, 07:19 PM |#11  
supercurio's Avatar
Retired Senior Recognized Developer
Flag Chambéry
Thanks Meter: 5,095
 
Donate to Me
More
Quote:
Originally Posted by Entropy512

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.
Post Reply Subscribe to Thread

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes