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) :

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) :

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.

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.

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.

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.

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.

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...)

XDA Developers was founded by developers, for developers. It is now a valuable resource for people who want to make the most of their mobile devices, from customizing the look and feel to adding new functionality.Are you a developer?