Root exploit on Exynos

http://forum.xda-developers.com/showthread.php?p=35469999#post35469999

by sigkill • 14 years ago

106 55 14 years ago

sigkill3• 14 years ago

I 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• 14 years ago

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.

ge0rg• 14 years ago

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).

codesuela• 14 years ago

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?

shawn-butler2• 14 years ago

The camera will stop functioning. You will get a black or green screen I imagine.

lotsofpulp• 14 years ago

Fixed in new Cyanogen build:

http://forum.xda-developers.com/showthread.php?p=35516282

hosay1234• 14 years ago

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.

joenathan3• 14 years ago

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.

mtgx2• 14 years 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.

hosay1234• 14 years ago

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.

marshray• 14 years ago

> 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.

mich413• 14 years ago

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.

RyanZAG4• 14 years ago

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.

pjmlp• 14 years ago

This is to be expect for any operating system that becomes interesting enough for attacks.

Maybe when micro-kernels finally manage to become mainstream, or security rules like LinuxSE and similar, can the problem be minimized.

RyanZAG4• 14 years ago

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.

ajross2• 14 years ago

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.

rbanffy• 14 years ago

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.

mich413• 14 years ago

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.

bobcattr2• 14 years ago

Can you explain what this has to do with the GPL?

Inufu• 14 years ago

iirc, 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.

mich413• 14 years ago

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.

wzdd• 14 years ago

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.

martinced• 14 years ago

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 : )

RyanZAG4• 14 years ago

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)

https://github.com/Ryan-ZA/exynosfix

https://github.com/Ryan-ZA/exynosfix/raw/master/exynosfix.ap...

voltagex_• 14 years ago

Thanks.

I've shortlinked the apk at http://bit.ly/exynosfix to allow easier downloading on the phone itself.

rakkhi• 14 years ago

Hm... I want to download it but it is a sideload APK and I'm too paranoid. Hope Google releases a fix ASAP

thefreeman• 14 years ago

Here's another link I found which does not require root.

http://project-voodoo.org/articles/instant-fix-app-for-exyno...

lewispollard• 14 years ago

Less vulnerable, but now my camera doesn't work. Is there any way to fix that besides waiting for the official update?

clebio• 14 years ago

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.

solox3• 14 years ago

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.

felideon• 14 years ago

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.

mathieuh• 14 years ago

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?

tinco2• 14 years ago

Why do we need to remember that?

charliesome• 14 years ago

Because matthieuh is an obvious Android fanboy :)

mikeash2• 14 years ago

Sorry, did I miss the part where this was just a competition to see who's worse?

tinco2• 14 years ago

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.

nwh• 14 years ago

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.

Root exploit on Exynos

Related Stories