[ROOT][SECURITY] Root exploit on Exynos

alephzain

Senior Member
Sep 29, 2010
117
2,791
0
EDIT: For general discussion about this topic, please post in the following location (and not here): http://forum.xda-developers.com/showthread.php?t=2057818

Now find a one-click root application at http://forum.xda-developers.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

Last edited:

AndreiLux

Senior Member
Jul 9, 2011
3,209
14,595
0
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.
 
Last edited:

Chainfire

Moderator Emeritus / Senior Recognized Developer -
Oct 2, 2007
11,439
87,667
263
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://forum.xda-developers.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 :)
 
Last edited:

RyanZA

Senior Member
Jan 21, 2006
2,023
778
0
JHB
Last edited by a moderator:

Entropy512

Senior Recognized Developer
Aug 31, 2007
14,095
25,085
0
Owego, NY
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? [email protected] 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.
 
Last edited:

supercurio

Retired Senior Recognized Developer
May 31, 2010
3,546
5,041
263
Chambéry
spectrastudy.com
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

Senior Recognized Developer
Aug 31, 2007
14,095
25,085
0
Owego, NY
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.
 

Entropy512

Senior Recognized Developer
Aug 31, 2007
14,095
25,085
0
Owego, NY
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...)
 
Last edited:

supercurio

Retired Senior Recognized Developer
May 31, 2010
3,546
5,041
263
Chambéry
spectrastudy.com
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.
 

Entropy512

Senior Recognized Developer
Aug 31, 2007
14,095
25,085
0
Owego, NY
Because your shell is in graphics group.
I was beginning to suspect that, thanks for confirming.

if this is a Samsung kernel issue would any of the custom kernel have the same flaws? otherwise would I be able to workaround the problem by installing a CM10 ROM instead of stock?
Right now older custom kernels will. CM's codebase was just patched earlier today to restrict that node to system.graphics 0660

It was done in the 10.1 branch, so it won't immediately affect all devices. We're working on transitioning all exynos4 devices over to 10.1 this week - it's about halfway done.
 

supercurio

Retired Senior Recognized Developer
May 31, 2010
3,546
5,041
263
Chambéry
spectrastudy.com
@alephzain, when running the exploit in an adb shell, sometimes the privilege escalation fails with:

Code:
[*] s_show->seq_printf format string found at: 0xC07A70A8

[*] sys_setresuid found at 0xC00945A0

[*] patching sys_setresuid at 0xC00945E4
[!] set user root failed: Operation not permitted
And it typically succeed after 1 or 2 more attempts.
Does it ring a bell?
 

Chainfire

Moderator Emeritus / Senior Recognized Developer -
Oct 2, 2007
11,439
87,667
263
www.chainfire.eu
ExynosAbuse APK updated to v1.10

I've just updated the ExynosAbuse APK to v1.10 !

This version allows you to disable the exploit (which may break camera), re-enable the exploit (if you need the camera) and to disable the exploit at boot (before any Android app runs). These options do require root (SuperSU or Superuser) to be installed as well. This is for people who actually *want* root. If you don't want root, you should use Supercurio's solution as it doesn't depend on being rooted it for dis/reenabling the exploit.

http://forum.xda-developers.com/showthread.php?t=2050297
 

supercurio

Retired Senior Recognized Developer
May 31, 2010
3,546
5,041
263
Chambéry
spectrastudy.com
Last edited by a moderator:

RyanZA

Senior Member
Jan 21, 2006
2,023
778
0
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/raw/master/exynosfix.apk

Ryan
As per requests, I added in 'fix vulnerability on boot' functionality for those who like an open source fix.

Nice work on that app, curio. :)
 

AndreiLux

Senior Member
Jul 9, 2011
3,209
14,595
0
Sooooo....

Here's a low-level fix for the kernel.

Source @ https://github.com/AndreiLux/Perseus-S3/commit/fb36195dab87e002721c7d1a8294a400c6b40a71
Edit: Follow-up commit for Note 2 (Possibly N8000 too) users @ https://github.com/AndreiLux/Perseus-S3/commit/81c95f6046880be48ef377ebae4e42c791f0813e

I did what I said in the first post. The mmap function checks the given memory addresses against all of the current CMA memory spaces on the device and denies access if the space it out of bound of any of the defined blocks. Furthermore on my S3 I, for now, couldn't find anything breaking beyond the main camera. So I added an additional condition that checks that the accessed memory block is "s3c-fimc" (The camera DMA block) and ignores the other blocks. The whole thing is totally neutered if CONFIG_CMA_DMA isn't used in the device configuration (Note 2 / Exynos 4412 devices with 2GB RAM). Edit: Fix works now the same for all devices.
Defined memory spaces:
Code:
[    0.000000] c0 cma: CMA: reserved 16 MiB at 65800000
[    0.000000] c0 [cma_region_descriptor_add] adding [s3c-fimc] (0x65800000)-(0x00f00000)
[    0.000000] c0 cma: CMA: reserved 40 MiB at 5c800000
[    0.000000] c0 [cma_region_descriptor_add] adding [s3c-mfc] (0x5c800000)-(0x02800000)
....
....
[    0.000000] c0 S5P/CMA: Reserved 0x70000000/0x00a00000 for 'fimc_is'
[    0.000000] c0 [cma_region_descriptor_add] adding [fimc_is] (0x70000000)-(0x00a00000)
[    0.000000] c0 S5P/CMA: Reserved 0x71700000/0x00800000 for 'fimd'
[    0.000000] c0 [cma_region_descriptor_add] adding [fimd] (0x71700000)-(0x00800000)
[    0.000000] c0 S5P/CMA: Reserved 0x6c300000/0x03d00000 for 'fimc0'
[    0.000000] c0 [cma_region_descriptor_add] adding [fimc0] (0x6c300000)-(0x03d00000)
[    0.000000] c0 S5P/CMA: Reserved 0x71600000/0x00100000 for 'srp'
[    0.000000] c0 [cma_region_descriptor_add] adding [srp] (0x71600000)-(0x00100000)
[    0.000000] c0 [cma_region_descriptor_add] adding [mfc-normal] (0x64000000)-(0x00400000)
[    0.000000] c0 S5P/CMA: Reserved 0x64000000/0x00400000 for 'mfc-normal'
[    0.000000] c0 [cma_region_descriptor_add] adding [mfc-normal] (0x64000000)-(0x00400000)
[    0.000000] c0 S5P/CMA: Reserving 0x6800000 for secure region aligned by 0x4000000.
[    0.000000] c0 S5P/CMA: Reserved 0x5c000000/0x06800000 for 'secure_region'
[    0.000000] c0 S5P/CMA: Reserved 0x5c000000/0x00800000 for 'sectbl'
[    0.000000] c0 [cma_region_descriptor_add] adding [sectbl] (0x5c000000)-(0x00800000)
[    0.000000] c0 S5P/CMA: Reserved 0x5c100000/0x03100000 for 'mfc-secure'
[    0.000000] c0 [cma_region_descriptor_add] adding [mfc-secure] (0x5c100000)-(0x03100000)
[    0.000000] c0 S5P/CMA: Reserved 0x5f200000/0x02f00000 for 'ion'
[    0.000000] c0 [cma_region_descriptor_add] adding [ion] (0x5f200000)-(0x02f00000)
Running the exploit:
Code:
[email protected]:/ $ export PATH=/data/local/bin:$PATH
 [email protected]:/ $ ./exynos-abuse
 [!] Error mmap: Invalid argument|00000004
Behind the scenes during that:
Code:
[ 119.290791] c1 [exynos_mem_open:50] private_data(0xd0340b80)
 [ 119.290889] c1 [exynos_mem_mmap] requesting access to (0x40000000)-(0x41000000)
 [ 119.290960] c1 [exynos_mem_mmap] Checking space paddr(0x65800000)-(0x66700000) from 's3c-fimc'
 [ 119.291046] c1 [exynos_mem_mmap] Checking space paddr(0x5c800000)-(0x5f000000) from 's3c-mfc'
 [ 119.291299] c1 [exynos_mem_mmap] Checking space paddr(0x70000000)-(0x70a00000) from 'fimc_is'
 [ 119.291386] c1 [exynos_mem_mmap] Checking space paddr(0x71700000)-(0x71f00000) from 'fimd'
 [ 119.291465] c1 [exynos_mem_mmap] Checking space paddr(0x6c300000)-(0x70000000) from 'fimc0'
 [ 119.291545] c1 [exynos_mem_mmap] Checking space paddr(0x71600000)-(0x71700000) from 'srp'
 [ 119.291631] c1 [exynos_mem_mmap] Checking space paddr(0x64000000)-(0x64400000) from 'mfc-normal'
 [ 119.291711] c1 [exynos_mem_mmap] Checking space paddr(0x64000000)-(0x64400000) from 'mfc-normal'
 [ 119.291801] c1 [exynos_mem_mmap] Checking space paddr(0x5c000000)-(0x5c800000) from 'sectbl'
 [ 119.291888] c1 [exynos_mem_mmap] Checking space paddr(0x5c100000)-(0x5f200000) from 'mfc-secure'
 [ 119.291967] c1 [exynos_mem_mmap] Checking space paddr(0x5f200000)-(0x62100000) from 'ion'
 [ 119.292034] c1 [exynos_mem_mmap] invalid paddr(0x40000000)-(0x41000000), accessing outside of DMA spaces
 [ 119.292798] c1 [exynos_mem_release:58] private_data(0xd0340b80)

I didn't care about the permissions set to the sysfs interface as they don't matter anymore.

I'll be deploying the fix tomorrow throughout my kernels.

The only things that needs to be checked by then is if something else breaks, as HDMI or so. I can't test any of that since I don't have a dongle. In that case anyway the kernel log will tell you what other memory space is accessed and I can open that one up too if needed.

Note: Galaxy S2 / 4210 developers may have to add cma_region_descriptor_add calls to from wherever the memory blocks are defined (Machine file definition or arch/arm/plat-s5p/reserve_mem.c). My commit will work as is on S3 and N2 sources.

I'm off to bed.
 
Last edited:

julandroid

Senior Member
Jun 3, 2011
50
4
0
and to disable the exploit at boot (before any Android app runs).
Cannot protect efficiently against some potential attacks (typically, on boot).
First, thank you both for the hard work and quick release.

The main question here is, how efficient is the current implementation in both applications, regarding the protection at start up?

As long as I understand Chainfire somehow ensures that the fix will be applied before running any other (normal) application. Is it possible to install a new application, which to put itself on top of execution chain and exploit the hole, before your application is able to do a 0600 chmod?

If I understand correctly the supercurio's app doesn't promise anything on that matter?! If that is the case, then I guess the recommended app (for rooted phones) will be the Chainfire's solution, right?
 
Last edited:
  • Like
Reactions: phonegeek24

Chainfire

Moderator Emeritus / Senior Recognized Developer -
Oct 2, 2007
11,439
87,667
263
www.chainfire.eu
First, thank you both for the hard work and quick release.

The main question here is, how efficient is the current implementation in both applications, regarding the protection at start up?

As long as I understand Chainfire somehow ensures that the fix will be applied before running any other (normal) application. Is it possible to install a new application, which to put itself on top of execution chain and exploit the hole, before your application is able to do a 0600 chmod?

If I understand correctly the supercurio's app doesn't promise anything on that matter?! If that is the case, then I guess the recommended app (for rooted phones) will be the Chainfire's solution, right?
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 or 0000. 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.
 
Last edited:

Yank555

Senior Member
Sep 18, 2009
8,716
19,947
263
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
 

Chainfire

Moderator Emeritus / Senior Recognized Developer -
Oct 2, 2007
11,439
87,667
263
www.chainfire.eu
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.