Samsung Phones: Every app has full memory access | Hacker News Reader

Samsung Phones: Every app has full memory access

forum.xda-developers.com

87 pointsitry49 comments

Any app has full memory access via /dev/exynos-mem

Largest security hole ever?

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.

As unpopular a suggestion as this may be, Blackberry's are very secure particularly if you enable some of the more advanced security features such as secure memory and full device encryption. A lot of research has been undertaken at my University into this recently and very little progress has been made.

The obvious downside is that the App eco system is still very poor compared to both iOS and Android and the UI leaves a lot to be desired. It depends really on whether you favour security over usability.

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.

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.

This is just one on the list of a few I've seen. There was also the infamous remote execution of USSD codes and another major exploit via the document reader(If I remember correctly some people where hyping that as an NFC attck).

I understand bugs and exploits happen, but this proc interface and the USSD attack were just silly. I'd just like something designed inside a culture of security.

A stock iPhone (non-jailbroken)? There hasn't been any widespread security hole since the early days of jailbreaking via PNG. iOS6 fixed a couple hundred security issues, almost all in webkit (those end up in Android & BB as well).

Blackberry 7 has been considered the most secure, but it's a huge step backwards from Android. We don't know about BB10 yet.

If a non-jailbroken phone is secure, then how is it possible to jailbreak it?

With physical access to the device. There still isn't an untethered jailbreak for iOS6. And even after a jailbreak, your data remains encrypted.

Jailbreak software uses 0-day attacks found by a small group of very skilled researchers/developers, which end up fixed in the next release. The same way you can root android.

An unjailbroken iOS device.

I would specifically recommended against the BlackBerry option others have offered. It is a poorly-coded platform (complete with an old, expoitable WebKit browser and J2ME) that is a popular hacking target (despite being practically dead in the consumer space) it still sees lots of use by lucrative targets in the corporate/govt space.

For all its power and awesomeness, I would also recommend against Android (vanilla or otherwise) if your focus is on security and data integrity.

Edit: You can downvote me, but consider the contrast in difficulty between rooting/jailbreaking iOS (and the iOS BootROM) vs. rooting/unlocking any given Android device's system and bootloader as a class example.

iOS has a jailbreak for every single version. Some have even used a variety of exploits to do this straight from the web. Apple have no magic up their sleeve that makes iOS 'more secure'; they are running on a normal CPU with a normal kernel. Apple users are more proactive in updating because they're nagged by the interface they're forced to use (iTunes) to update.

Apple users are more proactive in updating because they're nagged by the interface they're forced to use (iTunes) to update.

The reason doesn't matter here, does it?

It's also because updates are certain to be available for several years after a device's launch. Unlike some Android handsets, for which support is quickly abandoned.

Jailbreaking is generally voluntary on the user's part. Correct me if I'm wrong but insofar as you could jailbreak an ios device by visiting a url that would be an epic zero day exploit. Apple's secret is not allowing you to download and execute code from random websites. Oh, and memory protection.

The exploit used in comex's jailbreakme was just a PDF vulnerability. Sliding the "slide to jailbreak" simply loaded the correct PDF with some JavaScript; it wasn't actually needed.

Memory protection? That's a basic feature of a kernel? Are we talking about each platform's ability for native code to mmap() executable memory or something?

I think he's talking about stuff like ASLR, which didn't even begin to approach robustness until Android 4.1. iOS has had the jump (pun intended) on that for a while.

The original article concerns a bypass of application address space.

> iOS has a jailbreak for every single version.

This is absolutely untrue [1] and frankly, you have no clue what you are talking about. Please leave your platform cheerleading at the door.

iOS 6.x can be jailbroken on some older devices because the hardware is pwned. This is "Once I have physical access, I own the whole castle" in practice.

But the latest versions of iOS still haven't been broken on the 4S (which isn't owned hardware-wise), 5, iPad 2, iPad 3, iPad 4, iPad Mini.

IOW, the last two generations of iOS devices.

And when a version is jailbroken, Apple patches it pretty quickly -- thereby closing that vulnerability to malicious attackers.

> Apple have no magic up their sleeve that makes iOS 'more secure'

Actually, they have a range of security technologies that make iOS more secure. [2]

> Apple users are more proactive in updating because they're nagged by the interface they're forced to use (iTunes) to update.

I don't get nagged. I get a popup, which I can dismiss. And I get a little red 1 on my Settings icon. I am not nagged. But to tell the truth, I wish Apple would follow Android's suit and make it nag the living hell out of you. That would get more iOS users to stay current. But studies show they keep pretty current anyway and I'm not sure why it works so well, to be honest.

1.http://www.jailbrea.kr/

2. http://images.apple.com/ipad/business/docs/iOS_Security_May1...

>Please leave your platform cheerleading at the door.

And then you link me to an Apple security document that basically says (but in Apple style) "we encrypt a lot of stuff and use standard kernel-level security".

If it's "standard", why is Google not doing it/doing it half-assed with Android? I think that's my entire point, which you continue to ignore.

I don't know of an Android version on any device that isn't rooted. There might be a few in the small minority, though. Most every bootloader, with the exception of several Motorola bootloaders, has been cracked/unlocked, etc.

Why not flash CM on there? Not sure what kernel they're using for your S3, but its probably not the stock Samsung one. Even then, patches will be first from CM and months later (if ever) from the OEM & Carrier's internal politics that controls your phone.

Or if you want to spend money, a Nexus phone is your best bet. No carrier/OEM customizations and Google seems to give a shit about security and stability. This is what I have and I recommend it.

Man, I'd love to buy a Samsung Note, but Touchwiz scares me. Its a security nightmare, gaudy as all hell, slow, battery drain, and only gets updated when Samsung and T-mobile think it should get updated.

I'm also looking into Windows phone as android is becoming a nightmare of "too many cooks" and Google doesn't seem to have the ability or desire to stop this mess.

In the comments, someone mentions its a problem on CM too, because the problem is the Samsung driver itself - the camera works by doing direct memory access via this module, but it isn't restricted to the right memory regions.

Someone did post a fix if you're building your own: http://forum.xda-developers.com/showpost.php?p=35541696&...

CM has already been updated with the fix

Get as close to the OS vendor as possible. Less deviation from original intent, presumably more focus on engineering (yes, I know Nexus phones aren't made by Google, but by various vendors who also make their "own" versions), and you get updates much faster in the event of a security concern.

I have an S3 - I knew I was getting outside of the Android ecosystem to some degree when I first powered up the phone and saw the AT&T logo splash screen. Then you get into the phone and see all the cute little Samsung apps. Reminds me of buying a Windows PC :-)

You can regain some of what I described above by rooting and locking your phone down.

However, as you described your needs, an iPhone is ideal. An Android phone gives you a lot of power, but it doesn't sound like you need that much power, and for most people, security trumps customization.

what do you need a "serious secure phone" for?

Android's "open".

Seriously. since Android is open anyone can just patch this up and distribute it to millions of affected Android phones worldwide. There's nothing to worry about!

Use the phones that all intelligence agencies use: Blackberry.

Give a CIA tech an iPhone, Android, or WinPho, and he'll have access to all of your data (on the phone) before you've finished putting the phone down. Comparing the security on these devices to the security of a Blackberry is like comparing picket fences to the shield walls of Mordor.

Blackberry's may not be hip, but they were designed from the beginning to be secure.

No, this isn't true.

Perhaps you have forgotten Willem Pinckaers, a reverse engineer for Matasano Security in California, and Vincenzo Iozzo breaking the blackberry at Pwn2Own?

http://news.ycombinator.com/item?id=4928277

Now all I can think of is #droidrage

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.

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.

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

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

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.

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

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

Some sort of certification process before being allowed to ship customized builds would seem to do it. Or simply disallowing any custom builds at all: OS vendor builds all drivers, provides a list of supported hardware, and that's all you get to choose from.

> Some sort of certification process before being allowed to ship customized builds would seem to do it.

You still haven't answered what the requirement is, just that Google should have requirements and enforce them. What requirement specifically would have prevented this error?

And Android does require a certification process in order for a device to be called an Android device, just not one that would be helpful here [1].

> Or simply disallowing any custom builds at all: OS vendor builds all drivers, provides a list of supported hardware, and that's all you get to choose from.

Considering how reluctant most device manufacturers are to give up their customized builds, how well do you think the ecosystem would respond to disallowing all customizations? And just because you disallow customizations, doesn't mean that all of the code suddenly comes from one company. Samsung (as the SoC manufacturer) and their component suppliers still provide (potentially vulnerable) firmware. Google has a much larger job to do in order to support even a fraction of the available chipsets, as well as a much larger job to do supporting external companies (what happens when there's a kernel bug in somebody else's phones? how long are the individual chipsets supported? etc. etc.)

Besides, part of the point of Android is to allow for different companies to build phones for people who want different things, while remaining compatible with the rest of the ecosystem. Barring customization is almost the antithesis of the project's goals.

[1]: http://source.android.com/compatibility/overview.html

> You still haven't answered what the requirement is, just that Google should have requirements and enforce them. What requirement specifically would have prevented this error?

I suggested one that you quoted directly below your question. Come on....

Yes, it would be tough to do within the ecosystem. I'm not saying it would be easy. I'm not even saying it would be a good idea. I'm simply saying that it is possible.

Am I bad at communicating my thoughts? It seems like people regularly reply to my comments after reading things I never intended, and attacking me for it. I don't get it. Am I including subtexts I don't intend? Do people just insist on imagining things that aren't there? What's the deal?

> I suggested one that you quoted directly below your question.

So far the two suggestions have been "Don't let anyone but Google write code", which is pretty much the antithesis of the Android project. Nevermind the fact that Samsung has to write code (firmware, etc.) for their SoCs anyways.

> Yes, it would be tough to do within the ecosystem. I'm not saying it would be easy. I'm not even saying it would be a good idea. I'm simply saying that it is possible.

Alright, I kind of agree that this is a possible solution (though disagree in part because, as I've pointed out a couple times, Samsung does inevitably have to write code for the platform). I didn't understand this to be a requirement however because this "requirement for certification" is the equivalent of not allowing users to install software so they can't get a virus. Apologies for this confusion, though I would still like to see a requirement that didn't require an effectively closed system.

And I think it's obvious I believe this to be a terrible solution, but you don't appear to either agree or disagree with me there :)

> Am I bad at communicating my thoughts? It seems like people regularly reply to my comments after reading things I never intended, and attacking me for it. I don't get it. Am I including subtexts I don't intend? Do people just insist on imagining things that aren't there? What's the deal?

Actually, I don't think you're bad at communicating your thoughts, but text is inherently a lossy protocol for communication. I do, however, think you're reading too much into what other people write. I disagree with you, yes, but I wasn't attacking you then, nor am I trying to attack you now. I really am just trying to explain why I believe one thing while trying to get you to explain why you believe another. And I believe (or at least hope) this was somewhat successful, because I certainly have a better understanding of where you're coming from now.

Don't operating systems, like windows, have a secure memory space that only the core OS can access? Memory access violation?

Edit: I don't understand the complete issue, I just know there was something about accessing all the memory.

With so many Samsung Android phones (http://en.wikipedia.org/wiki/Comparison_of_Android_devices#S...) 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.

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.

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

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

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.

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

My carrier phone in Canada finally updated to Jelly Bean 4.1 last night. My dad has the same phone bought the same day and he's still on the pending list to get the update...

so, not fast?

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.

Reply on news.ycombinator.com