This is a pretty serious security risk and it's highly recommended to make yourself immune ASAP. This is the kind of exploit that can go viral very quickly in Google Play and the results of a malicious process with root access can be very severe.
If your device is rooted, here is a very simple app that will let you toggle world-access permissions to the file and secure your device (until a true fix is released)
It's a sideload APK so that you know exactly what you're downloading. Google Play search can often give you malware with an identical seeming name and icon to real apps. Since this app requires root, it's very important to know exactly what it does - that is why it is OSS and I highly recommend anybody who knows Java to double-check that the app is non-malicious.
Relying on Google Play for a root-requiring app is not in any way a guarantee of safety - you can upload a malicious app to Google Play, and it can sometimes be as much as 24 hours before it is taken down.
Correct method is to download the source from github, verify it is correct, and compile and build your own version. Failing ability for you to do that, get someone you trust to verify the code, and failing that, try and make sure that there are no comments about the app being malicious.
Could the camera app be wrapped with this in a way that r/w is restored when the camera is launched, and then removed again when closed (back-grounded, home-screen press, whatever)? I can't check the APK myself right now, but seems at least plausible.
Unfortunately, giving userspace direct access to the hardware is quite common GPL-circumvention technique used by embedded vendors.
One creative example I've seen was an x86 mITX motherboard targeted at the embedded market whose "Linux driver package" included kernel module implementing a simple virtual machine which executed programs uploaded by userspace and gave them unrestricted access to the x86 IO space.
It's not really about GPL violation, it's about laziness. There are plenty of things Samsung could have done to work around the GPL without opening a massive hole. For example, they could have created a user-space server, which either mapped /dev/mem directly (as root, and then dropped permissions) or mapped this special device but was only given permission to do so after some cryptographic check by the kernel: a simple hash of the text would have sufficed.
This is just a dumb mistake, on par with the original Android G1 release which ran everything you typed on the keyboard in a root shell.
Writing closed-source Linux kernel modules is legally "difficult". It is generally believed that modules which make use of highly Linux-specific internal infrastructure can be considered derived works of the kernel and thus required to be released under GPL. It's not always perfectly clear what is allowed and what is not and hardware vendors are reluctant to find it out in court. Some kernel APIs are explicitly marked as not callable from proprietary modules and the module loader enforces this. As a famous example, NVIDIA claims that inability to use one of these APIs prevents them from supporting Optimus in their video driver.
Hardware vendors who don't want to open their drivers need to work around these issues. They can either divide the driver into open-source Linux-specific part and closed-source "hardware support library" which avoids calling suspicious kernel APIs, or simply move the whole driver to a userspace shared library and give userspace processes access to the hardware.
Userspace components are expressly excluded from being considered derived works of the kernel by text at the top of its license. Within the kernel, individual symbols (e.g. function calls) are explicitly tagged with a bit that tells the kernel whether they can be used by non-GPL code, and the kernel checks this at runtime.
It's painful to watch Android deal with endemic security problems that Windows began addressing over a decade ago. Note this isn't the first occurrence of crapware resulting from OS customization ending up on a few million Android devices, I remember at least one more vendor shipping a setuid root binary.
Can anyone comment on Windows 8's customization model from the manufacturer's perspective? A wild guess is that something like this is much less likely: even if a driver leaves some kernel object unsecured, access is difficult given how heavily walled off native APIs are on WinRT.
Samsung intentionally created new kernel-userspace interface to bypass normal kernel security mechanisms and give userspace direct access to RAM and IO registers, allowing them to put low-level device drivers in userspace. I'm pretty sure that somebody writing a Windows driver for this hardware could use the same "architecture" as well.
However, Windows is less likely to see such hacks because they are usually created to avoid dealing with kernel's GPL.
Userspace is really not the issue here at all. The problem is that the device was given full access permissions to every role on the system, when it should have been (trivially) limited to only system services. All of Android is userspace and relies on the kernel's userspace protection system (standard unix permissions) for security.
It's just a major mistake on Samsung's side that could have been avoided with 5 seconds of thought by the engineer.
This exploit doesn't have anything to do with "crapware", it has to do with a flawed implementation of how the camera accesses the memory.
The code in the Windows kernel is never touched by anyone outside of Microsoft, unlike Android where is it necessary for every OEM to have to modify the kernel just to get Android to run on their device.
To compare Android to Windows Phone or Windows RT, the issue is one of closed source versus open source. Microsoft bakes support for certain SOC into Windows Phones kernel, which is why all Windows Phones have the same specs. The open nature of Android leaves it vulnerable to OEMs screwing things up.
I've no doubt the authors of Carrier IQ would say its keylogger had nothing to do with crapware, merely being a flawed implementation of "measuring operational information in Android devices", the end effect is the same.
The Windows kernel is touched by anyone who ever writes a driver for it, in other words every vendor shipping a Windows 8 tablet or phone today, or historically for any vendors that shipped Windows CE devices (which was the market I was comparing to, but it's also been true on desktops for all history).
The customization referred to is where carriers or hardware vendors takes white label software (Android, Windows CE, Windows 8), adds their own juice in the form of spyware, drivers, preinstalled apps, clicks a button and out pops something that gets flashed to devices.
My comment was comparing security properties of customization processes of the two operating systems, not making any argument (which would require claims to disputed facts – I don't believe I made any).
> The code in the Windows kernel is never touched by anyone outside of Microsoft
Not exactly true. Device manufacturers and antimalware vendors add kernelmode device drivers all the time. It's not unheard of for very similar problems with that code to be found.
Half the problem is that Linux's module interface is intentionally hobbled for non-GPL users, and in any case has no stable, versioned API. There'll probably never be something like a 'generic binary' Android, as there is Windows, that users just add some extra modules to, and that is by design.
Unless there is something I an missing, having a big kernel taking up RAM and disk space with support for hardware your phone doesn't have would be a waist of limited resources.
It would make porting CyanogenMod and other custom ROM's a lot easier to other phones, so I don't think that would be a waste. If manufacturers aren't going to support the devices anymore, at least the community will. Plus, it should make it a little easier for manufacturers, too.
The important difference is that nobody outside Microsoft can tell you whether something like this is in their current releases - and Microsoft will never say a word about it.
With Android we don't need to wait for Samsung or Google to acknowledge the problem and fix it. As someone else pointed out, Cyanogenmod is already patched.
That causality is wrong. The vulnerability doesn't exist because Samsung products are attractive to exploit. It's a brain-damaged driver (exposes physical memory directly, which even /dev/mem doesn't anymore; and it's created with global write priviledges, meaning that literally no one with a clue about security ever looked at it). Samsung screwed up badly here.
A microkernel wouldn't have helped them here -- it looks to me like this driver exists precisely to defeat the existing protections that prevent userspace access to device memory. If that was the requirement, no kernel architecture would have helped this.
This problem (carelessness) cannot be minimized by micro-kernels or any other technical system, as this is not a technical fault. Samsung parked the company Mercedes in the middle of nowhere and left the key in the ignition and the engine running.
You may have done the same thing before - created a network share of your photos for others to see, but forgot to set the permissions to read-only instead of writable? This is exactly what Samsung did - they specifically marked a device with direct access to the devices memory as writable by everyone.
There are simply no technical solutions to incompetence ;) - this should never have made it out of engineering, let alone past QA.
Having seen Samsung engineering practices at first hand this doesn't surprise me. I'd put money on this not being an issue on the Nexus 10, where the Google Android team would have been involved with the product.
According to http://forum.xda-developers.com/showthread.php?t=2050297 the N10 is an Exynos5 device and thus not compatible anyway. Not sure though if the Google team is reviewing the whole set of patches (and if such a patch would not slip through their hands).
this exploit is probably connected more to the company than the processor. If they can rubberstamp (or not even realize they're) shipping hacks like this they could be doing it again.
Holy crap, tried this on my S 3 too (custom rom Cyanogenmod derived MIUI) with the same result. I guess chmoding it to the proper permissions (0600) will cause all kinds of different issues, won't it?
I am replying to you assuming that you and your parent will be able to see this.
Just tested this. Details first - Custom ROM (based on ICS). Stock google camera app (based on ICS).
"chmod 0600 /dev/exynos-mem" works well. The file permissions then shows crw------- as expected. The camera app still works fine. I tried recording videos and capturing pictures and was successful (1080p & 8MPx settings). Looking at the file permission after launching the camera app still shows no change (i.e. if it was 0600, it remains 0600). However, when I reboot the phone, the file's permission returns to 666. I have done this entire process three times just to be sure, and the file's permissions always returns to the default values.
Might need to look into it further, but frankly I don't have the time nowadays.
Would require further investigation. However, running the camera app via a non-priviliged account and also removing access would have the effect of removing DMA to the camera, that is why I suggested the result might be a black or green screen. I suppose it's possible they have some other way of taking stills, but I can pretty much guarantee you aren't going to record 1080p without DMA.
The proper solution is to obviously limit the DMA to regions of memory only needed by the camera. From my albeit cursory glance of the issue, it seems like you can pretty much write to any region of memory.
I have to imagine an exploit of that gaping a security hole is not very far away given the huge install base of samsung exynos devices.
I stand corrected. I tried for a fourth time, and apparently, after chmodding you need to wait for a minute or two. After that if you open the camera app, there is a black screen, exactly as you described.
EDIT - I still don't understand. The camera seems to be completely controlled by black magic. I have not recorded, but opening/closing the camera, then changing the permissions seems to allow you to continue using the camera app even with (0600).
Probably because the camera service was still running and has already opened the file before you change the permissions. Changing permissions doesn't affect existing file descriptors.
You can probably change it in /uevent.boardname.d - substitute in the board that you see. If you see uevent.goldfish.d, you can ignore that one. (It's for the emulator.) Let me know if it works for you.
This file is located on the initrd on the boot image, however, so you have to pull the boot image, split it, extract the initrd, change the uevent file, repack it, and flash it.
Does no one remember when iOS had a zero day exploit which allowed root access when visiting a site with a PDF using a certain font? The one that took Apple five months to fix?
That's one way to interpret it, another way is to assume matthieu is indicating to us that these vendor locked distributions are shit, not necessarily one shittier than the other.
Both Android and IOS suffer from these problems that would obviously be toothless if the platforms would just be on github, and the phones could simply be reflashed with custom builds at will.
It was down to an exploit in LibTIFF though, which also effected devices like the PSP and software like Adobe Reader. Apple has done more bizarre things on their devices, like giving root access to the iTunes synching agent in iOS 1.x.
The "original" Galaxy S devices (I9000, Epic 4G, Vibrant, Captivate, Fascinate, and Mesmerize), which also use the Exynos processor, are not affected for some reason.
Is this a fact? That does seem to be my impression after trying a 'ls -l /dev/exynos-mem' on my own Galaxy S running CM7, but I'm otherwise unable to conclude if there is still a vulnerability.
I'm so happy to be running an old crappy Nokia "no-apps, not even J2ME" phone.
We read the other day that Kaspersky preferred to run a very simple phone for security reasons.
I wonder if other security-savvy people like Bruce Schneier etc. are using the latest gizmos (be it from Apple, Samsung, Microsoft or any other) or, well, just something that allows to give and receive phone calls.
Can't wait to see a botnet of 40 millions Samsung devices.
It's really sad this kind of headlines give a bad rep to Google, Android and Linux (even if the "culprit" is Samsung).
I'll wait a few more years and see how things turn out but meanwhile I keep my good old phone that, you know, allows to give and receive phone calls : )
If your device is rooted, here is a very simple app that will let you toggle world-access permissions to the file and secure your device (until a true fix is released)
https://github.com/Ryan-ZA/exynosfix
https://github.com/Ryan-ZA/exynosfix/raw/master/exynosfix.ap...