

Root exploit on Exynos - sigkill
http://forum.xda-developers.com/showthread.php?p=35469999#post35469999

======
RyanZAG
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...](https://github.com/Ryan-
ZA/exynosfix/raw/master/exynosfix.apk)

~~~
voltagex_
Thanks.

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

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

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

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

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

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

~~~
bobcattr
So the userspace driver uses the same syscalls or they need to do the work
around. I guess I am most interested in the workarounds.

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

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

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

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

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

~~~
oconnore
<http://en.wikipedia.org/wiki/Conditional_compilation>

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

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

------
lotsofpulp
Fixed in new Cyanogen build:

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

------
mathieuh
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?

~~~
tinco
Why do we need to remember that?

~~~
charliesome
Because matthieuh is an obvious Android fanboy :)

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

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

