7 ms·
Root exploit on Exynos
- sigkill 14y agoI just tried it in a terminal on my Galaxy S2. It has a completely custom rom (F1Nexus), and the output of ls -l /dev/exynos-mem is crw-rw-rw- system graphics 1, 14 2012-12-09 07:59 exynos-mem Clearly, Samsung has completely dropped the ball here.
- edderly 14y agoHaving 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.
- ge0rg 14y agoAccording to http://forum.xda-developers.com/showthread.php?t=2050297 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).
- gravitronic 14y agothis 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.
- codesuela 14y agoHoly 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?
- shawn-butler 14y agoThe camera will stop functioning. You will get a black or green screen I imagine.
- sigkill 14y agoI 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.
- bryanallen22 14y agoYou 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.
- kelvie 14y agoYes, this is what you need to do. 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. I've done that, and it sticks on boot now.
- shawn-butler 14y agoWould 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.
- lotsofpulp 14y agoFixed in new Cyanogen build: http://forum.xda-developers.com/showthread.php?p=35516282 http://forum.xda-developers.com/showthread.php?p=35516282
- hosay123 14y agoIt'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.
- joenathan 14y agoThis 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.
- mtgx 14y ago>unlike Android where is it necessary for every OEM to have to modify the kernel just to get Android to run on their device. I think that will change once Android starts using the linux 3.7 kernel, which is supposed to unify ARM kernels.
- mich41 14y agoUnfortunately, 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.
- bobcattr 14y agoCan you explain what this has to do with the GPL?
- Inufu 14y agoiirc, if you write a kernel module you have to release it under GPL, but if it's just a user space program you can keep its source closed.
- mich41 14y agoWriting 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.
- bobcattr 14y agoSo the userspace driver uses the same syscalls or they need to do the work around. I guess I am most interested in the workarounds.
- martinced 14y agoI'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 : )
- RyanZAG 14y agoThis 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) https://github.com/Ryan-ZA/exynosfix https://github.com/Ryan-ZA/exynosfix https://github.com/Ryan-ZA/exynosfix/raw/master/exynosfix.apk https://github.com/Ryan-ZA/exynosfix/raw/master/exynosfix.ap...
- voltagex_ 14y agoThanks. I've shortlinked the apk at http://bit.ly/exynosfix http://bit.ly/exynosfix to allow easier downloading on the phone itself.
- rakkhi 14y agoHm... I want to download it but it is a sideload APK and I'm too paranoid. Hope Google releases a fix ASAP
- RyanZAG 14y agoIt'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.
- thefreeman 14y agoHere's another link I found which does not require root. http://project-voodoo.org/articles/instant-fix-app-for-exynos-mem-abuse-vulnerability-no-root-required-reversible http://project-voodoo.org/articles/instant-fix-app-for-exyno...
- solox3 14y agoThe "original" Galaxy S devices (I9000, Epic 4G, Vibrant, Captivate, Fascinate, and Mesmerize), which also use the Exynos processor, are not affected for some reason.
- felideon 14y agoIs 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.
- mathieuh 14y agoDoes 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?
- tinco 14y agoWhy do we need to remember that?
- charliesome 14y agoBecause matthieuh is an obvious Android fanboy :)
- mikeash 14y agoSorry, did I miss the part where this was just a competition to see who's worse?
- tinco 14y agoThat'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.
- mikeash 14y agoI can see how that would make it interesting to point out the vulnerability, but I don't see how it works with the "does no one remember?" phrasing.
- nwh 14y agoIt 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.