yashsingh1/xdaforums huggingface dataset:
[Galaxy Note II General] Chainfire:
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://xdaforums.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 :)
[Galaxy Note II General] thegh0sts:
would this trip the flash counter? my guess says no.
[Galaxy Note II General] 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?
[Galaxy Note II General] cypressious:
I'm not very good with Linux, but I did

chmod 600 /dev/exynos-mem

on my GSII international with CM10 and the camera still works. Am I safe for now?
[Galaxy Note II General] thebobp:
I'm guessing no, considering /dev/exynos-mem (why would they do that?) but does any similar vulnerability exist for the Qualcomm S3?
[Galaxy Note II General] garyd9:
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://xdaforums.com/showthread.php?t=2017367)
[Galaxy Note II General] 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.
[Galaxy Note II General] jcase:
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.
[Galaxy Note II General] supercurio:
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.
[Galaxy Note II General] yugoport:
In my point of view, we are a community of developers, not a bunch of people trying to help Sammy to solve the problems that their extremely well paid engineers can't see. .

I truly respect your point of view, and cheers to your sense of civism to try to protect the people that are using this phones and don't have ability and knowledge to protect themselves against a so severe lack of security, but seriously Sammy doesn't care about users or developers, they care about money. .So first I think he did well to post here and then inform Samsung.

Well pointed, for a discover like this they should pay a fortune to alephzain, and other devs that help fixing this security problems, but they just don't care. .

I'm sure they will fix it eventually in the next updates but they will encover it of course and will leave millions of users at risk until that. .they don't want this kind of publicity.

I hope that they give a good reward to our devs that everyday work to improve our devices. .but I know they will not do it. . But that's the fun of it isn't it?
[Galaxy Note II General] supercurio:
@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.
[Galaxy Note II General] garyd9:
Please keep this on topic: /dev/exynos-mem.
[Galaxy Note II General] supercurio:
This is not Samsung-specific in any way.

Fortunately most people discovering security flaws inform original authors so they can fix the issue and release updates before the exploit is publicly released.

I'm not judging alephzain here, because its possible he tried to report the issue but found no-one listening, taking him seriously, or simply couldn’t find who to contact, hence my question to him to know if he tried or just didn't care, also because I'm a fan of the technical exploit and use similar method in my apps as apps to do things not supposed to be done.

Millions of vulnerable devices are out there now. This exploit which is very well designed and I believe very hard to detect if carefully hidden inside an Android app.

It means privacy, security of a large amount of people and corporation is at a larger risk right now as the manufacturer didn't had the chance to provide a security fix to its users, because of not being aware of the issue.
[Galaxy Note II General] julandroid:
What a nuisance!

The most important question is - how to quickly patch this?

A simple chmod 0600 /dev/exynos-mem does not survive reboot.

Any ideas that does not envolve unpack/pack update images?
[Galaxy Note II General] supercurio:
Nobody wrote yet an app that fixes the issue?
[Galaxy Note II General] julandroid:
I don't care about the app right now. That's why those reports *should* go directly to the root of the problem - Samsung. Because once they go to the surface everyone can exploit the device. Eventually, if someone decide to post the exploit first - then it should be prepared with the solution.

For know it will be a good idea, anyone with knowledge just to give idea what to do (manually). For example I don't have any ueventd.smdk4x12.rc (Galaxy S2, CM10). I guess I need to unpack boot.img, to find where permissions are set for /dev/exynos-mem, then to repack boot.img and flash it.
[Galaxy Note II General] AndreiLux:
As far as I'm concerned I already implemented a fix into the kernel to just whitelist the FIMC0 memory space for the mmap function and to refuse access to the rest of lowmem. I'll post it later when I sorted some things with the other DMA spaces.
[Galaxy Note II General] supercurio:
Okay I feel lazy this Sunday night but will still quickly write an app that fixes the vulnerability (simple chmod 660) at boot.

Just for the sake of it.

(Breaks camera on S III, not on Note II)
[Galaxy Note II General] RyanZA:
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

MOD EDIT: Removed attached download, as it is out of date compared to the linked download
[Galaxy Note II General] supercurio:
Hey hello Ryan :)

Unfortunately it crashes on my S III, need logcat?
[Galaxy Note II General] Entropy512:
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.
[Galaxy Note II General] supercurio:
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!
[Galaxy Note II General] supercurio:
Yes there's a large variety of physical damage and other kind of bricking rendering the device in-operative, requiring replacing parts to fix it.

All this with root only.

I would have to describe those to make my point but obviously I will not :)
[Galaxy Note II General] RyanZA:
It crashes? Interesting :o Works here fine.. device must be rooted to use it, but I'm sure yours is rooted... If you could post the logcat would be interesting to see why something so simple would crash! You can check out the github source too if you want, it's been added to the post above.

Accepting git pull requests from anybody who wants to fix the crash. ;)

Ryan
[Galaxy Note II General] supercurio:
Oh that's why!

Yes I assumed it wouldn't need root, the app I'm writing doesn't require a rooted device.

You know, it's using the exploit to protect from further exploit :angel: and the target is "any user" with security concerns before Samsung pushes the official fixes.

I'm sorry, in order to operate the switch back and forth on non-rooted device I'm using a proprietary stuff developed for my other apps so I won't be able to share the source :(
[Galaxy Note II General] alephzain:
And at the other side there is people who don't inform authors and exploit security flaws in secret (ex Zero-Days)

I research a contact for samsung "security" mail but like you said : "simply couldn’t find who to contact".

So I decided to post here. Maybe it wasn't the best thing to do for you ... but it's done.

Now waiting the fix from Samsung, don't use camera for impacted devices by setting more restrictive permissions on /dev/exynos-mem.

AndreiLux seems to make good progress on fix. Thanks to him.

And a good start to see what is exactly done with /dev/exynos-mem is at : http://git.insignal.co.kr/samsung/exynos/android/platform/hardware/samsung_slsi/exynos4/ in libcamera, libhdmi and libgralloc_ump since samsung open some sources. I quickly check source and I guess we have all element to fix that.
[Galaxy Note II General] RyanZA:
Oh, 100%. Makes sense to me and would be good to distribute to users who aren't rooted. My app is just a quick fix made for the XDA community, and I'm sure most people here are very much rooted (and full of stock roms ;) )

To XDA users: I recommend you either run 'su' 'chmod 600 /dev/exynos-mem' or grab my app for easy access. This is the kind of exploit that is going to go viral in the Android Market within hours and you'd best be protected ASAP!

You will need to use 'chmod 666 /dev/exynos-mem' to use your camera (or use my app to toggle) until new custom roms/official roms can come out with a proper fix!
[Galaxy Note II General] supercurio:
@alephzain thanks for your answer. I believe it will help things going in the right direction.
[Galaxy Note II General] supercurio:
Do you think I would put my Google Play developer account at risk if I publish an app with this exploit (using it to protect from the exploit) on Google Play?

I'm asking you because you're very much an expert on this topic.
[Galaxy Note II General] capricornian:
Hey used ur app n camera worked even if it's in on mode.. :thumbup:
[Galaxy Note II General] RyanZA:
Yes, Google uses an automated detection system for vulnerabilities, and if they detect that your app has an exploit inside it your market account will be banned. Google is very difficult to talk to on issues like this and you'd have a hard time even getting hold of a real person to prove your app was 'for users benefit'.

So if you choose to publish the app to Google Play, I'd recommend creating an entirely new Google Play account, with new email and not linked to your real account (Google Play suspensions will 'cross over' to linked accounts).
[Galaxy Note II General] supercurio:
One Note II ? 600 perms works on my back & front Note II camera as well

On Galaxy S III 4.1.2, back camera is broken (green) and front is still okay.
[Galaxy Note II General] capricornian:
Nope S3 running unofficial cm10.1 build..
[Galaxy Note II General] supercurio:
Thanks for the recommendation.

I'm sure I could hide it in ways it would not be detected but I'll publish it on my blog instead.
[Galaxy Note II General] doggnz:
Thanks RyanZA. My camera still works with the fix on..? Not that I'm complaining :D
[Galaxy Note II General] RyanZA:
Camera on my device also continues to work fine, and I can confirm the permissions set by the app:

ls -l /dev/exynos-mem

crw------- system graphics 1, 14 2012-12-14 10:18 exynos-mem

Maybe only some devices require world-access to the exynos-mem file to use the camera.
[Galaxy Note II General] jcase:
Yes this vuln is serious, yes exploitable via any user, no it is not remote, calling it remote is just a gross overstatement, and is not correct in any way.

You are absolutely right, JTAG can fix wiping the partition map on HTC phones, that was a gross overstatement on my part.

I'm not going to argue with you on all the rest, it doesn't belong in this thread and with two hard headed people it would not be productive. If you want to talk about classification of vulnerabilities, update times, whether or not one could ruined an HTC phone via software or which OEMs we have hate for this week feel free to PM me, it is the kind of conversation I do enjoy.
[Galaxy Note II General] wchill:
The source code as is doesn't actually run any privileged code (other than su), does it? You'd have to store something such as -c cp /sdcard/new_su /system/bin/su to cmd[1]?

I'm looking into possibly using this for Root Transmission.

Sent from my Synergized Galaxy S3
[Galaxy Note II General] supercurio:
The exploit code gives you a root shell and you can interact with it as like any shell through stdin/stdout, which is very convenient and thanks again for this ;)
[Galaxy Note II General] Mad383Max:
Ditto here. Rear camera broke. Using 4.1.2 port jedi x6.1.2
[Galaxy Note II General] fards:
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..
[Galaxy Note II General] Entropy512:
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.
[Galaxy Note II General] Entropy512:
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...)
[Galaxy Note II General] supercurio:
Because your shell is in graphics group.
[Galaxy Note II General] Entropy512:
I was beginning to suspect that, thanks for confirming.

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.
[Galaxy Note II General] supercurio:
Work in progress for the non-root app

Let me know if it looks alight to you.
[Galaxy Note II General] supercurio:
@alephzain, when running the exploit in an adb shell, sometimes the privilege escalation fails with:

[*] 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?
[Galaxy Note II General] supercurio:
If you want too root please use Chainfire's app that does just that.

Its 0:20AM and I said I would release it before going to bed ;)

I prefer my apps doing one thing and doing it right anyway.
[Galaxy Note II General] garyd9:
Well, I was warned by the admin that this would eventually happen in this section, and it finally has. 28 posts deleted in only 3 pages. Sad. READ THE STICKY POST IN THIS SECTION BEFORE POSTING.

Be happy it's me deleting them and not a "real" admin (who would be.. or at least SHOULD be tossing out infractions, etc.)

The following are things that shouldn't have been posted here:

thank you

Nice

ooh..

ahhh...

They don't teach this in high school

Ripping Samsung for more BS (even though I agree with it)

Contacting Samsung (and flaming people about contacting samsung)

References to other applications (unless those other applications are directly related to the thread topic) This includes the several posts going back and forth about superuser/superSU.

Specific reports about "my device is (or is not) impacted" - unless you have damn complete details (device name, type, kernel, versions, kernel logs) you aren't contributing to the thread.

Report of other websites linking to this thread

Asking questions of "it my device impacted?" - if you don't understand the details in the original post, please don't post here.

"I'm almost done" posts (nothing personal, but if I'm going to be an a-hole, I have to do it for everyone.)

Edit: If you feel I deleted a post in error, please tell me which post (or at least give me an idea of which one) and I can re-evaluate. However, complaining that your post (or posts) were deleted in error without being more specific is about as useful as a so-called "bug report" saying "its not working" without giving any details, logs, etc.
[Galaxy Note II General] Chainfire:
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://xdaforums.com/showthread.php?t=2050297
[Galaxy Note II General] supercurio:
Voodoo Instant fix for Exynos Mem Abuse vulnerability released.

I'm glad I have a blog, because things tend to disappear here ^^

Edit: Please use the following thread to discuss this specific solution: http://xdaforums.com/showthread.php?t=2051290
[Galaxy Note II General] RyanZA:
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. :)
[Galaxy Note II General] julandroid:
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?