yashsingh1/xdaforums huggingface dataset:
[Galaxy Note II General] Chainfire:
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.
[Galaxy Note II General] Hungry Man:
Could you chown the file to be accessible only from a special group, and then run the samsung apps in that group with their separate users? This would allow compatibility while preventing arbitrary access from unprivileged applications.
[Galaxy Note II General] Yank555:
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
[Galaxy Note II General] Chainfire:
Correct. Modifying it in initramfs would be even quicker, but a generic app can't do that. Also chmod to 0400, not 0600.
[Galaxy Note II General] rsd2000:
Usergroups?

just my $0.02.

Isn't this a matter of using specific usergroup for the device?

Besides the driver implementation side, instead of chmoding to 0400/0600?

I - creating a group like exynos-mem

II - chgrp exynos-mem /dev/exynos-mem

||| - chmod 0440, 0660 or 0640 to /dev/exynos-mem

|V - adding camera app user (and anyother that needs it) to exynos-mem
[Galaxy Note II General] garyd9:
Which other apps need it? There are quite a few apps that use the camera... And many more on in the market. It'd be nearly impossible to maintain that.
[Galaxy Note II General] PIRATA!:
I'm sorry and I please the mods not to delete my post as I'm asking something that might interest the community.

@RyanZA ...have you opened a thread/topic here on XDA where you talk about your fix or you only have the Github source page that you link here and use to post only in this actual thread??

I ask this because your fix is mentioned as a third solution next to curio's and Chain's solutions...

Thank you.
[Galaxy Note II General] ...Awesome...:
Warning: Be very careful on what 3rd party apps you download that give FULL access to camera I was able to successfully install an app and control camera access via this exploit on Samsung GSIII & SG Note II.

Using ChainFire app does indeed block the exploit while the other 2 the exploit was still successfully run on the Galaxy SIII.

Obviously I will not post the exploit method but all users should be wary of downloading and checking what permission you are giving 3 rd party apps till this exploit can be patched via Samsung since you don't have to be rooted for this to work.
[Galaxy Note II General] manveru0:
hmmm as far as I had a look on both apps from chainfire and supercurio, both set the permission for /dev/exynos-mem to c---------

edit: only supercurios app does that, chainfires app sets the permission to cr--------

Edit: deleted statement about exploit because it was wrong and only leads to confusion
[Galaxy Note II General] Chainfire:
Are you sure you don't have root access in ADB shell, as I've tried the exploit manually after fixing on three different devices and it does not work (nor would it make any sense if it did) on any of them with only "shell" access. Is your prompt $ or # ?
[Galaxy Note II General] Entropy512:
This is already the current implementation in CM10.1 - exynos-mem is 660 system.graphics

So you need to be running in the graphics group to use the exploit. 660 system.graphics will block the easiest routes to abuse, but it may be possible for an app with camera permissions to do the privilege escalation. Not sure.

That is why I'll be working on getting Andrei's patches integrated into the smdk4210 kernel tree tonight. I think I just need to port his mach-midas changes over to mach-u1. Also on CM, I need to port his mach-midas changes to mach-p4notepq

Andrei, can you clarify your comment about CONFIG_CMA_DMA? Are you saying the fix is neutered if that config isn't used? The way I read your post, it sounds like you're saying the fix won't work on Note2 or Note10.1 (Exynos devices with 2GB RAM)?

That's odd. 0600 should block shell users from exploiting - 660 won't as the shell user has graphics privileges.
[Galaxy Note II General] manveru0:
whooops, my mistake. Of course I was doing this while I was root. Both apps prevent the exploit if executed as a normal user as one would expect. I'd better delete my first post as this leads only to unclarification as it's statement is of course wrong
[Galaxy Note II General] AndreiLux:
I meant that the whole mmap function is neutered if that configuration isn't set; it will always return -EINVAL. Currently only the 1GB S3 has that option enabled and the CMA framework is used for the camera (until now, somebody will still have to test HDMI). I tested the patch as it is on an N2 and everything works as it should.

So recap:

CMA_DMA enabled: filters through all the memory blocks and only lets through s3c-fimc. (S3, likely needed on the 4210 devices too)

CMA_DMA disabled: blocks everything, makes the device driver basically useless. (Currently all the 2GB devices)

The fix can actually just be just condensed to two lines checking the hard-coded memory addresses of the fimc device and denying access if it doesn't match, but I guess like this it's more dynamic to the other spaces in case they might be needed. I like to over-engineer (and I also think Samsung will expand the CMA-DMA framework for more device drivers in the future).
[Galaxy Note II General] Entropy512:
OK, thanks for the clarification.

Interesting, I wonder how N80xx libcamera sets up FIMC then. This might be useful in getting opensource gralloc/HWC working better on CM10.1, your discovery tells me there's some way to use FIMC without having the reserved FIMC regions... hmm...

Insignal's reference source relies heavily on multiple FIMC memory regions. Mobile's less so - gralloc never uses/provides FIMC memory itself, but camera use a second FIMC engine (FIMC2 I think) as an abstraction layer for camera data. It sounds like Mobile's newest implementations use the FIMC engine without any need for FIMC reserved memory, or at least not without any need of mapping it via exynos-mem.
[Galaxy Note II General] renaud:
By telling this, you assume nobody else than alephzain knows about the vulnerability, which may be wrong. If there is a vulnerability, you have to tell it to the community (and Samsung obviously) so fixes can be released ASAP, if you don't allow the community to fix the problem it may already be too late and exploit may exist without you even knowing the vulnerability exists. If an exploit exists, there are chances the bad guys already know too and not telling will just make others vulnerable without any knowledge.
[Galaxy Note II General] TrayLunch:
Very true! But on the other hand, posting an open source exploit of the vulnerability rather than just notifying the community of its existence, is a bit dangerous.

I digress. We are long past discussing the merits of the actions taken. What's done is done, and the code has been out there long enough that those who would like to use it for nefarious purposes, have it by now. I'm sure both yours and my post will be deleted anyway.

Elite Tester for Mijjz Goodness
[Galaxy Note II General] rsd2000:
True.

A user that uses a tool like that is able to know Wichita other app fails to use the camera and manually add that to a whitelist.

Is every Joe user able to do this? Of course not. But he will barely be able to install such a tool in the first place. And if he does, the main camera app will work by default.
[Galaxy Note II General] kiwi_man:
I'm not up to play with code or anything like that but after reading this thread I am worried about what this exploit will allow 3rd party apps to do. I have a SGS2 running build number JZO54K.I9100XXLSJ (OTA Leak from samfirmware android 4.1.2). Does this exploit only exsist if using 3rd party apps that use the camera? Or is it just the way sammy have coded the kernel that the fixes may affect the camera? Sorry if not in relevant thread
[Galaxy Note II General] qazibasit:
Well it was us who in the initial days were happy about samsung phone, which can easily be rooted and easy to develop on. But now these are the consequences....

Thanks dev for the effort. Samsung is still silent and our OTA JB is once again late. It will again go in trials because of this issue.
[Galaxy Note II General] Vincent Law:
3rd party apps (or anything that gains executable status on your phone) can do whatever it wants. The exploit gives full access to all of physical memory. There's basically nothing they can't do given enough time.

The fix closes the exploit, but the problem is that the camera hardware needs the exploit in order to function. Basically, terrible, terrible programming.
[Galaxy Note II General] supercurio:
Hello Renaud

Of course no I don't assume that alephzain was the only one knowing about this vulnerability.

The community cannot fix the problem because despite we’re a loud we're a very small minority of users.

Releasing a very nicely designed and written, and also easy to use exploit allows script kiddies to abuse of the millions of users who won't ever get a fix unless the manufacturer or carrier publish it.

IMHO statistically the global risk is higher for a many more people if you release an exploit into the wild first instead of allowing vendors to fix the security issue.

That said, my recommendation to Samsung have been to open an easy security contact, and reward contributions by sending devices or financial compensation (bounties).

And you all know I'm not inventing anything here ;) Several companies and foundations do that for years.

It has been proposed, we'll see how it materialize.
[Galaxy Note II General] Yank555:
Hi,

I can confirm, restricting fileaccess to exynos-mem, while it will brake the camera on a 4.1.2 Samsung ROM, if you flash the old "/system/lib/hw/camera.smdk4x12.so" (4.1.1) the camera will work again (on Samsung Update 6 based kernel at least that is).

I can break the camera by flashing the 4.1.2 lib and make the camera work again by flashing the 4.1.1 lib, back and forth.

Looks like the old lib doesn't use exynos-mem...

BTW, the fileacces I use for exynos-mem is the one Chainfire suggested (r--------).

JP.
[Galaxy Note II General] punshkin:
Hey sorry for my dumb question, but

I don't think i fully understand this.

How is this more dangerous than any other root method/exploit? say one-klick-root?

Is this fix only for people that are not rooted and want to be protected against it or does it also protect rooted phones?
[Galaxy Note II General] supercurio:
Current one click root method requires you to USB tether your android device to a computer.

The real difference here is that any application can hide the exploit and use it to access all your personal data on your device, and possibly even damage the hardware.

It would have to be an application purposely malicious tho, but as you saw you don't need to plug your smartphone or tablet on USB.

A worse case scenario, which is not the case here would be an exploit that can be used directly from a webpage.

If none is documented right now, a very dangerous combination of 2 exploits in a row (in the browser + this one) would be extremely bad.

Chainfire's app is root-oriented, mine work regardless of your rooting status. (Chainfire's app offer a stronger protection tho)
[Galaxy Note II General] punshkin:
Thank you, Supercurio for explaining this on a level i can understand. :)

From what i understand now, such an App would not have to get SU access granted by SuperUser App to do harm, is that correct? better protect myself!
[Galaxy Note II General] supercurio:
Yes that's absolutely that.

With this vulnerability any application gets superuser privileges.

It could totally be used for cool stuff like Chainfire's demonstrated as an easy rooting method, but unfortunately not everyone has good intentions.

However in order not to fall into the FUD category its important to precise the main condition: running a malicious application on a vulnerable system.
[Galaxy Note II General] Entropy512:
Well, Samsungs have always been easily rootable *in a safe manner without exploits that make the system vulnerable to blackhats*. Rooting via flashing a system image in Odin pretty much can't be abused except if your device's physical security is compromised (someone grabs your device, flashes ??? to it, and returns it, a fairly unlikely attack scenario).

Doesn't surprise me... Samsung has changed their graphics architecture significantly (especially in terms of memory usage/allocation) at least 3-4 times in the past year (as evidenced by the wildly different reports of whether certain permissions changes break camera or not). Only one of those variations (that in new/old Insignal source and Hardkernel source) is documented, and that's so ancient that it predates any Samsung Mobile firmware release that ever shipped to users as far as I can tell.

I've backported Andrei's patch to Exynos 4210. It seems to be working:

shell@android:/data/local/tmp $ ./exynos-abuse
[!] Error mmap: Invalid argument|40067121
1|shell@android:/data/local/tmp $

This previously succeeded.

Camera seems to be as working as it was before - photos and video still work. hwaccel video decode also works other than Netflix, but Netflix was busted to begin with.

Patch is now under Gerrit review at: http://review.cyanogenmod.org/#/c/28568/
[Galaxy Note II General] pongster:
On an N7100 4.1.2 ROM , I have observed that using Andrei's patch causes the camera to fail and not even show the green screen.

Changing permissions to 0400 or 0600 for /dev/exynos-mem stops the exploit, as posted by the OP, from gaining a root shell. However, these 2 permissions break the rear camera and give me a green screen on 4.1.2.

Setting the permissions to 0606 or rw for others is the only way I can get camera working on 4.1.2.

What workaround would allow me to have camera working while stopping the exploit from potentially causing any damage? I can use Chainfire's app (and let users toggle it for camera to work when they need it) but it could get cumbersome for users.

Using an older 4.1.1 camera .so might work as some have confirmed, so does that mean we need Samsung to update/revert to use a camera .so that doesn't need /dev/exynos-mem to have others with rw access so that restricting permissions on it fixes the exploit and gets camera working on 4.1.2 Samsung Stock ROM's?
[Galaxy Note II General] Yank555:
Using the 4.1.1 camera .so (1 file) is all that is required on a 4.1.2 ROM to make camera work even if fileaccess to eynos-mem is 400 (on i9300 at least). Everything linked works, too, video recording, best face etc.

JP.

PS : I posted the libs here.

Sent from my custom Paranoid Android 2.54 / Yank555.lu CM10 kernel v1.3d Aroma (Linux 3.0.57) powered Galaxy S3 i9300 using Tapatalk 2
[Galaxy Note II General] debernardis:
Could you please attach the old file to share? Thanks
[Galaxy Note II General] Yank555:
I posted them here.

JP.

PS: I also added the link to my prior post.
[Galaxy Note II General] PIRATA!:
Hehe yeah, long time!

Your idea is great. Hopefully this exploit will be fixed, but for the moment you guys just rock!

Take a look at the fix someone found for the camera on S3....but I know you might already know: http://xdaforums.com/showthread.php?t=2052675

---------- Post added at 10:23 AM ---------- Previous post was at 10:16 AM ----------

Same for you: this guy linked up here found 4.1.2 lib collection that fix the camera on S3.
[Galaxy Note II General] Chainfire:
(snipped some lines)

I mean no offense, but mine only requires root because I feel that is easier process, and yours also requires root but it does so silently in the background. That's an implementation difference. The true difference here is that mine cannot be done without modifying /system, and that's the only true difference (the rest is just words and perception).

As for these "serious" medias (pfft), the only possible reason they felt confident enough posting about your solution instead of mine is (again, no offense intended) because they're complete retards who have no idea about security. Both your and RyanZA's solutions are not secure - and if I was a malware author, they would not stop me. As such, anybody using your or RyanZA's solution right now thinks they're safe while actually they're not much safer than before.
[Galaxy Note II General] debernardis:
Fyi the Avast antivirus now recognizes Chainfire's Exynos Abuse as a malware.

This might mean it is able of recognizing applications which invoke the exploit.

Even Supercurio's app get recognized.
[Galaxy Note II General] pongster:
Confirming that the N7100 4.1.1 camera.smdk4x12.so works even when /dev/exynos-mem is at 0400.

As a quick hack for those who need the protection and can't be bothered to toggle an app to use the camera, this is OK for now... While we wait for how Samsung plans to fix it.

Now I set perms of /dev/exynos-mem to 0400 in ueventd.smdk4x12.rc and run an md5sum check on the camera.smdk4x12.so to see if it needs replacing. If any malicious code were to exploit it, it would have to be run before the ueventd perms are set.

Have been testing all video functions so far and the old lib isn't causing any problems. (I can't test HDMI though as my MHL cable is the old one from the S2 and won't work on N2)

It's not as low level as Andrei's fix but its a compromise so users can be protected while having full use of their camera.
[Galaxy Note II General] AndreiLux:
I explained in my post how to check the accessed memory space, just start the camera and check dmesg afterwards. Post the log and I'll tell you how to fix it. Alternatively just remove the CMA_DMA check at the top of the mmap function. I'll release my N2 kernel in the evening so I'll figure it out myself.

Replacing the camera with old libraries is a stupid fix and we won't be able to stick with the old files forever.

It's also an insecure fix, if you're already doing a custom kernel with the permissions changed in the code or ramfs init, then you might as well just remove the device driver creating exynos-mem and close the hole altogether, because as long as it's there and my patch isn't included inside the kernel, you will be able to abuse it.
[Galaxy Note II General] Entropy512:
I'm confused... Since you maintain your own kernel, why not just pull in Andrei's patch?

Edit: Ooops, missed one of your posts. I'm guessing you need to make an alteration to your patch to do the cma_add_region_descriptor calls in specific locations. The 4210 patch might be of use to you - on 4210, mach-u1 contained a duplicate of the reserve_mem.c implementation for CMA stuff. I'm guessing the issues you encountered will also affect N80xx, which I plan on looking at tonight.
[Galaxy Note II General] AndreiLux:
The N7100 doesn't have CMA_DMA active in the defconfig, so I was probably wrong in the assumption that it is a kernel side condition, and 4.1.2 libraries directly access the fimc block regardless of that option. If that's the case then the fix is to just remove that check. I'll test it out and report back soon enough. All the N2 variants use mach-midas.c as their device file since it's the same hardware platform as the S3.

Edit: Here's a follow-up commit with that variation of the camera libraries: https://github.com/AndreiLux/Perseus-S3/commit/81c95f6046880be48ef377ebae4e42c791f0813e

<6>[ 916.697437] c0 [exynos_mem_mmap] requesting access to (0x65c00000)-(0x661ef000)
<6>[ 916.697489] c0 [exynos_mem_mmap] Checking space paddr(0x70000000)-(0x70bcc000) from 'fimc_is'
<6>[ 916.697538] c0 [exynos_mem_mmap] Checking space paddr(0x6f800000)-(0x70000000) from 'fimd'
<6>[ 916.697584] c0 [exynos_mem_mmap] Checking space paddr(0x6bb00000)-(0x6f800000) from 'fimc0'
<6>[ 916.697631] c0 [exynos_mem_mmap] Checking space paddr(0x70ef4000)-(0x70ff4000) from 'srp'
[B][COLOR="Red"] <6>[ 916.697679] c0 [exynos_mem_mmap] Checking space paddr(0x65c00000)-(0x66b00000) from 'fimc1'
<6>[ 916.697730] c0 [exynos_mem_mmap] Accessing space 0x65c00000/0x00f00000 for 'fimc1'[/COLOR][/B]
<6>[ 916.697866] c0 [exynos_mem_mmap] Checking space paddr(0x64000000)-(0x64400000) from 'mfc-normal'
<6>[ 916.697963] c0 [exynos_mem_mmap] Checking space paddr(0x5c000000)-(0x5c100000) from 'sectbl'
<6>[ 916.698008] c0 [exynos_mem_mmap] Checking space paddr(0x5c100000)-(0x5f200000) from 'mfc-secure'
<6>[ 916.698054] c0 [exynos_mem_mmap] Checking space paddr(0x5f200000)-(0x63800000) from 'ion'
<7>[ 916.698306] c0 [exynos_mem_mmap_open] addr(0x45b0f000)
[Galaxy Note II General] Chainfire:
In case anybody cares, I've posted an in-depth article regarding the app-based patches here: Why Exynos exploit patches may not work as expected + demo app
[Galaxy Note II General] Entropy512:
WRONG. DEAD WRONG.

Where the hell do people get the utterly stupid idea that a privilege escalation exploit that can be used by *anything* to gain root priveleges only affects rooted devices?

It is, fundamentally, a way for ANYTHING to ROOT YOUR DEVICE WITHOUT YOU EVEN KNOWING IT HAPPENED.
[Galaxy Note II General] RyanZA:
Luckily you aren't a malware author then, or we'd all be screwed! ;)

Of the current 4 malware using this exploit I know of in the wild, all run on app start - which is blocked by all 3 solutions. Supercurios solution works on non-rooted devices, and therefore has by far the best chance to help the most people (blocks all known malware + works for non-rooted devices). Fixing the problem for as many people as possible as soon as possible before Samsung can roll out real fixes is the real goal here, and supercurios does that goal the best - so it's pretty clear why the poor "serious" medias have posted it. :)

People on XDA who want to feel super secure should definitely install a custom kernel to fix the issue - but this is a bit much for most common users to attempt!
[Galaxy Note II General] shoey63:
Exactly. If Chainfire can make an APK to root your phone and/or suppress the exploit ,Surely cybercriminals can do the same with malicious intent, under the guise of installing some seemingly innocuous App.:eek:
[Galaxy Note II General] Chainfire:
I've replied to this in more detail in the other thread, but IMHO this is complete nonsense. There is no such thing as "super secure". Either your secure, or your not secure. Anything else is just a false sense of security.

Am I seriously going to have to brick a million devices before any of you develop any common sense ?