

Samsung Phones: Every app has full memory access - itry
http://forum.xda-developers.com/showthread.php?t=2048511
Any app has full memory access via /dev/exynos-mem<p>Largest security hole ever?
======
stusmall
I currently have an S3 and this isn't the first serious exploit I've come
across for it.

Does anyone have any suggestions for a serious secure phone? I don't need all
the bells and whistles and don't install many apps. Mostly just email, text,
and web browsing.

~~~
driverdan
This is only a serious exploit if you install an app that exploits it. If you
only use email, SMS/text and web browsing and don't install any apps you
should be fine.

If you want a more secure Android phone get Google's (currently Nexus 4). It
won't have all the BS that 3rd parties add, like this.

~~~
fulafel
It's a break from the sandbox so any vulnerability in an app (eg outdated
WebKit, the norm on non-google devices) now compromised your whole device.

------
thefreeman
<http://news.ycombinator.com/item?id=4928277>

------
JimmaDaRustla
Now all I can think of is #droidrage

~~~
mtgx
Oh yeah, Microsoft's vitriolic campaign against Android. But this is not about
Android per se, but about Samsung's drivers for the camera, and giving camera
full access to root, because they were lazy.

~~~
mikeash
I'm conflicted. On one hand, this is definitely Samsung's fault, not Android
in general. On the other hand, an OS with more rigorous requirements for OEMs
could have prevented this.

~~~
mdwrigh2
I'm curious what requirement you think would prevent this.

~~~
cube13
Apple's approach(no OEMs at all, known hardware) would mitigate the problem
somewhat. But that doesn't stop lazy idiots from screwing up at Apple, and it
doesn't work for anyone that's providing a general-purpose OS.

That's really about it. This is a kernel-level driver issue, caused by a lazy
Samsung coder. Unfortunately, the drivers need that level of access, since
they're used by Android to actually work. I'd say normal *nix kernel security
practices should apply here, but that still doesn't stop lazy idiots...

~~~
mdwrigh2
So the "more rigorous requirements for OEMs" is "no OEMs at all"? Seems a
little like throwing the baby out with the bathwater. Besides, part of the
point of Android is having an OS which allows for companies like Samsung to
build their own variants.

Also, the problem isn't unknown hardware (as you would suggest by saying they
should use "known hardware"). If it was an issue where they unknowingly left
the hardware in some strange debugging state so that userland could query the
it for restricted information, then it would be an issue with unknown
hardware. In this case they directly and intentionally provided unprotected
access to all of memory. That's just bad engineering.

~~~
cube13
>Also, the problem isn't unknown hardware (as you would suggest by saying they
should use "known hardware").

No, the failure point here is, essentially, unknown hardware from Google's
perspective. Android is not coded to work specifically with Samsung's
configurations or hardware, so Samsung needs to provide drivers. As for "more
rigorous" requirements, I don't think it's too hard to have the requirement
that all drivers follow standard *nix security practices. That would have
stopped this completely.

So the solution is to either not allow custom OEM builds(which, as I noted,
isn't possible for Android).

~~~
mdwrigh2
> No, the failure point here is, essentially, unknown hardware from Google's
> perspective. Android is not coded to work specifically with Samsung's
> configurations or hardware, so Samsung needs to provide drivers. As for
> "more rigorous" requirements, I don't think it's too hard to have the
> requirement that all drivers follow standard * nix security practices. That
> would have stopped this completely.

This is obviously a boneheaded mistake, but how do you verify that all drivers
follow "* nix security practices" (and I'm still not entirely clear _exactly_
what those are nor how they differ from generic security practices) short of
an in-depth security audit for each new piece of hardware. It isn't enough to
_have_ requirements, you have to have to be able to validate them.

>So the solution is to either not allow custom OEM builds(which, as I noted,
isn't possible for Android).

Is there a second part to this "either"?

------
chenster
With so many Samsung Android phones
([http://en.wikipedia.org/wiki/Comparison_of_Android_devices#S...](http://en.wikipedia.org/wiki/Comparison_of_Android_devices#Samsung))
flooding out to stay competitive and get a quick win over the iOS as well as
other manufacturer's Android devices, it's obvious that some of their stuffs
will eventually fall through the crack as result of poor QA. I will not be too
surprised to see other brand Android phones have similar security issues.

I can almost see that Android is quickly becoming the next Windows 95.

------
itry
Looks like on Samsung devices, every app has full r/w memory acess via
/dev/exynos-mem

I wonder two things:

1) if this is Samsung only or if its an Android issue.

2) If and how this can bee used to become root. TFA says "The good news is we
can easily obtain root on these devices" but doesnt say how.

------
lostlogin
Is anyone else finding that thread full of Google adverts for Samsung phones?
It's rather funny.

------
drivebyacct2
How was this even posted? It's the exact same link as yesterday in addition to
the other link about this yesterday.

Ah, I see the original has an anchor in the URL:
<http://news.ycombinator.com/item?id=4928277>

~~~
japaget
The title on this post is clearer. I have heard of Samsung phones (and
Android), but I didn't know what Exynos was so I skipped over the initial
link.

------
berntb
As an Android newbie -- how easy is it to get out kernel patches to [all these
millions of users'] phones?

(No, I'm not a black hat -- I don't have a hat of _any_ colour.)

~~~
ricardobeat
Not easy. Most carriers delay updates, sometimes by years, because of all the
custom crap they layer on top, or for no reason at all.

