Attend XDA's Second Annual Developer Conference, XDA:DevCon 2014!
5,731,698 Members 48,968 Now Online
XDA Developers Android and Mobile Development Forum

[ROOT][SECURITY] Root exploit on Exynos

Tip us?
 
alephzain
Old
(Last edited by alephzain; 8th February 2013 at 06:36 PM.) Reason: discussion orientation
#1  
alephzain's Avatar
Senior Member - OP
Thanks Meter 1980
Posts: 117
Join Date: Sep 2010

 
DONATE TO ME
Prompt [ROOT][SECURITY] Root exploit on Exynos

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, 23794 views)
The Following 290 Users Say Thank You to alephzain For This Useful Post: [ Click to Expand ]
 
AndreiLux
Old
(Last edited by AndreiLux; 18th December 2012 at 08:03 PM.)
#2  
AndreiLux's Avatar
Senior Member
Thanks Meter 13595
Posts: 2,748
Join Date: Jul 2011

 
DONATE TO ME
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 50 Users Say Thank You to AndreiLux For This Useful Post: [ Click to Expand ]
 
Chainfire
Old
(Last edited by Chainfire; 17th December 2012 at 01:43 AM.)
#3  
Chainfire's Avatar
Senior Moderator / Senior Recognized Developer - Where is my shirt?
Thanks Meter 48689
Posts: 8,982
Join Date: Oct 2007

 
DONATE TO ME
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
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
Samsung i5800, i9000*2, P1000*2, P7100, i9100*2, N7000, P6800, i9300, N7100, i9505, N9005
Sony T LT30p, Z C6603
Nexus Galaxy*2, N7, N10, N7-2013

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 136 Users Say Thank You to Chainfire For This Useful Post: [ Click to Expand ]
 
supercurio
Old
#4  
supercurio's Avatar
Senior Recognized Developer
Thanks Meter 5070
Posts: 3,529
Join Date: May 2010
Location: Chambéry

 
DONATE TO ME
@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.
The Following 7 Users Say Thank You to supercurio For This Useful Post: [ Click to Expand ]
 
RyanZA
Old
(Last edited by Chainfire; 18th December 2012 at 12:06 PM.) Reason: Added github
#5  
Senior Member
Thanks Meter 731
Posts: 2,021
Join Date: Jan 2006
Location: JHB
Hey curio,

No need, here is a very quickly put together app in 5 mins that lets you toggle on/off world writability to /dev/exynos-mem

So you can toggle the fix off if you want to use the camera, then toggle it back on afterwards.
Github source: https://github.com/Ryan-ZA/exynosfix

APK Download: https://github.com/Ryan-ZA/exynosfix.../exynosfix.apk

Ryan

MOD EDIT: Removed attached download, as it is out of date compared to the linked download
Need stuff done? Give me a shout, maybe I can help: http://www.mobile-dev.co.za/
The Following 16 Users Say Thank You to RyanZA For This Useful Post: [ Click to Expand ]
 
Entropy512
Old
(Last edited by Entropy512; 16th December 2012 at 07:54 PM.)
#6  
Senior Recognized Developer
Thanks Meter 24092
Posts: 13,133
Join Date: Aug 2007
Location: Owego, NY

 
DONATE TO ME
Quote:
Originally Posted by jcase View Post
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.
OK, we're getting into technicalities here, but I consider anything that can be exploited by a Market app without explicit user intervention beyond installing an app (reboot cycles, ADB, etc.) to be "remote". Adam covered how easy it is to bypass Bouncer at BABBQ, so relying on that is a bad idea.

Prior to this, all exploits (restoreRoot, mempodroid, etc) for ICS on Exynos4 devices required ADB to be involved. This doesn't.

And no, you can't cause permanent damage to an HTC with root. The example you provided isn't permanent damage, it can be repaired via JTAG at a service center. Superbrick is *permanent unrecoverable damage that requires a motherboard replacement - JTAG cannot bring a device that has been damaged back to operation*. That's a difference between 0 material costs and maybe 30 minutes of labor to repair at a service center and $200-300+ in material costs and significantly more labor.

And your "updates take considerable time" is bull****. Sprint FI27 was built on September 27 (check the kernel build date), 3 weeks after Samsung had the final version of their protection patch, and was deployed on Kies a matter of *days* later. They had an update scheduled, a patch ready to go for three weeks before the update was built, and they shipped without the patch. There's no excuse for that. At that time, it was an "open source problem" because it only affected custom firmwares, and any root exploits known required ADB. Their approach was dependent on an assumption that *an exploit like this would never happen* - which is a horrible assumption.

This exploit changes things - there is no a root exploit that can be used by an app straight from the market, in the background, with little to no user intervention.

As to the negative effects of 600 permissions on operation (such as killing camera) - as an interim, setting things to 660 instead of 666 makes things somewhat better protected but not as protected as they should be. I will run some tests later today to confirm that at least any old APK can't get privilege elevation if things are set so only the graphics group can diddle with the memory regions.
*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 10 Users Say Thank You to Entropy512 For This Useful Post: [ Click to Expand ]
 
supercurio
Old
#7  
supercurio's Avatar
Senior Recognized Developer
Thanks Meter 5070
Posts: 3,529
Join Date: May 2010
Location: Chambéry

 
DONATE TO ME
Quote:
Originally Posted by RyanZA View Post
Hey curio,

No need, here is a very quickly put together app in 5 mins that lets you toggle on/off world writability to /dev/exynos-mem

So you can toggle the fix off if you want to use the camera, then toggle it back on afterwards. Will update this post shortly with github source.

Ryan
Yes what I also started writing allows to restore permissions on /dev/exynos-mem in case you need to use camera, I agree its useful!
 
Entropy512
Old
#8  
Senior Recognized Developer
Thanks Meter 24092
Posts: 13,133
Join Date: Aug 2007
Location: Owego, NY

 
DONATE TO ME
Quote:
Originally Posted by fards View Post
Camera is insisting on 666 on some builds.
Curious how some devices using same base code are using camera with diff permissions.
Neither my N7000 or N 8010 will play nicely with 600 or 660..
The assumption of similar base code isn't a good one... You'd be shocked how many deltas there are between I9100/I777/N7000 stock firmware codebases that shouldn't be there given how similar the devices are.

In the region of the system we're dealing with here (graphics memory allocation), there are significant differences in operation between Exynos 4210 and 4412. There are also significant deltas between the implementations in all of Samsung Mobile's devices and the official public reference source, and frequently deltas between Samsung's implementations for various handsets/tablets that shouldn't be there as you've discovered.

For example, the official reference source does allocations from FIMC1 memory regions in gralloc to support various graphics items. Nearly all of Mobile's implementations allocate ION memory instead of FIMC1 memory even when FIMC1 memory is requested (and yes, this change affects camera operation more than anything else.)

Thanks for the headsup on N80xx, I'll def. have to do a rebuild on N8013. It's pretty frequent for us to have brokenness that doesn't exist on I9300 and vice versa.
*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 2 Users Say Thank You to Entropy512 For This Useful Post: [ Click to Expand ]
 
Entropy512
Old
(Last edited by Entropy512; 16th December 2012 at 09:56 PM.)
#9  
Senior Recognized Developer
Thanks Meter 24092
Posts: 13,133
Join Date: Aug 2007
Location: Owego, NY

 
DONATE TO ME
Hmm, odd... even when chmodded 660 system.graphics, the exploit appears to succeed on CM10.1 from within an ADB shell...

I need to look more closely at this.

Seems like the shell user is a member of the graphics group...

I think AndreiLux's approach he's working on may be the best.

Has anyone tested to see what the effect of 0600 is on hwaccel video playback? (Seems to be none on CM10.1).

Looks like it's anything that wants FIMC memory that needs exynos-mem, I'll double check ION, that should have failed...

Edit: Yeah, gralloc only accesses exynos-mem when attempting to access FIMC1 memory. I think camera is the main other place where FIMC is used. Actually, in any shipped handset, gralloc should never actually access exynos-mem - gralloc will give ION memory when you ask it for FIMC1 memory, and ION memory allocation doesn't use exynos-mem (hmm, unless libsecion does... I need to check that...)
*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 3 Users Say Thank You to Entropy512 For This Useful Post: [ Click to Expand ]
 
supercurio
Old
#10  
supercurio's Avatar
Senior Recognized Developer
Thanks Meter 5070
Posts: 3,529
Join Date: May 2010
Location: Chambéry

 
DONATE TO ME
Quote:
Originally Posted by Entropy512 View Post
Hmm, odd... even when chmodded 660 system.graphics, the exploit appears to succeed on CM10.1 from within an ADB shell...

I need to look more closely at this.

Seems like the shell user is a member of the graphics group...

I think AndreiLux's approach he's working on may be the best.
Because your shell is in graphics group.

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

Advanced Search
Display Modes