Why an unhackable mobile phone is a complete marketing myth

https://techcrunch.com/2016/10/08/why-an-unhackable-mobile-phone-is-a-complete-marketing-myth/

by sidcool • 10 years ago

67 73 10 years ago

Correct. As long as you have Turing Complete machines you made theoretical hack possible. This was nicely illustrated by the problem that Ethereum had a while ago while it would not be possible on Turing incomplete-Bitcoin.

Phithagoras• 10 years ago

Could you post that Ethereum problem as a story and/or comment? Curious to read it

hueving• 10 years ago

I'm guessing op is just referring to the DAO disaster.

feklar• 10 years ago

This also explained it well, predicting contracts would be full of problems http://vessenes.com/ethereum-contracts-are-going-to-be-candy...

mynameislegion• 10 years ago

That's not the problem; the problem is a lack of awareness about object-capability theory. zooko nailed it: https://twitter.com/zooko/status/748683889934163969

If you have time, read up on the basics: http://www.erights.org/talks/promises/paper/tgc05-submitted....

drdeca4• 10 years ago

I don't follow.

Suppose you have a Turing complete machine, with network connection, programmed to respond to 1 particular message with a particular message, and ignore all other messages. It seems clear that this should be possible to make secure against attackers who cannot do physical attacks?

I am not sure what you mean.

sebastianconcpt6• 10 years ago

That machine you have, because can do general computations (Turing Complete) can be attacked on that message until its stack dumps and you have access to perform general computations on the underlying system where that program was running.

witty_username2• 10 years ago

As long as you have Turing Complete machines you made theoretical hack possible.

This is false theoretically.

sebastianconcpt6• 10 years ago

Why? Can you elaborate on demonstrating that is false?

ufmace2• 10 years ago

Seems useless and pointlessly breathless to me to even talk about something being "unhackable". What's important is hackable by who, and in what way.

If you turn off Android's setting to only allow app installs from the play store, then install a sketchy third-party store and download a flashlight app with a huge permission list that scrapes your email address book and sends it off to Russia, is that really a hack? It's pretty tough to prevent that without locking the phone down even harder than the iPhone. Doesn't seem worth worrying much about to me.

Android seems to be pretty safe against more dangerous stuff like visiting a website or displaying a web ad installs an app, bypassing user approval. Or worse, doing something with root permissions. At least I haven't heard of anything like that. If it's out there, presumably whoever has found such exploits keeps them under wraps for high-value targets.

The Stagefright one sounded pretty dangerous, but I haven't heard of any large-scale attacks with it in the wild. Presumably carrier-level general protections against mass MMSing and specifically against payloads for that bug were effective.

Given the difficulties the Android rooting community seems to be having, it's hard to believe that a drive-by exploit could gain persistent root.

tarancato• 10 years ago

Problem with Android is the amount of devices that will never get updates.

How many devices are there in the wild that have yet to be patched against stagefright? I bet it's over 50%

ufmace2• 10 years ago

Just spent a little while googling around for Android security info, and I'm feeling pretty safe. I haven't been able to find any reports of anybody actually doing anything interesting off of the Stagefright exploit. Sounds like Android is pretty good at defense in depth. Though Stagefright is bad, it sounds like getting from whatever it does to anything interesting to any potential attackers is not easy, and if anybody knows how to do it, they aren't talking about it or using it widely.

One of the more interesting exploit dissections I read was of a 2013 Pwn2Own exploit of Chrome on Android[0] good enough to earn the designer $50k. Long story short, a series of vulnerabilities are exploited through Javascript of a visited webpage eventually resulting in sending that Chrome's cookies to a remote server. Impressive effort, and certainly not good, but then again, how many people have any important cookies in their mobile Chrome? And how many websites will actually allow you to do something that is interesting to an attacker after you hijack somebody's cookies? Of course those bugs are long since fixed on all Androids, since it's in Chrome. Even if they were active, I still wouldn't worry much, because you can't get much interesting info unless you can get system/root permission and read the data of all of the other apps on the device.

Actually, if I was designing that as an actual attack, I think I'd send off the autofill info too. That ought to be possible for an exploit that can read the cookie jar, and it sounds much more likely to contain credit card info, home addresses, and other stuff an attacker might be able to monetize.

[0] https://docs.google.com/document/d/1tHElG04AJR5OR2Ex-m_Jsmc8...

pjmlp6• 10 years ago

Maybe you should go through the actual set of issues.

"Presentation on Threats and Vulnerabilities in Android OS"

https://www.youtube.com/watch?v=CZAejnPrqJc

"Android: Protecting the Kernel by Jeffrey Vander Stoep, Google"

https://www.youtube.com/watch?v=WxbOq8IGEiE

fnkym0nky• 10 years ago

Android is notoriously broken among the AppSec community. For proof all you have to do is look at the last 90 days of Android bug reports[1]. The reason why your not hearing of exploits is because of the price war that currently exists for them. Zerodium recently raised the price for a Android RCE to $200,000, with iPhone RCEs at 1.5 million[2].

[1] https://source.android.com/security/bulletin/2016-10-01.html [2] https://www.zerodium.com/program.html

pjmlp6• 10 years ago

After watching the presentations about the state of the union in regards to kernel security in Android, I came to realize that I was wrong in bashing Google for their constrained NDK.

Actually, they should constrain it even more, given the poor state of kernel exploits and how the whole security updates doesn't happen across Android devices.

walterbell9• 10 years ago

A wifi-only device (tablet or iPod Touch or other music player) can connect over VPN+wifi to a mobile hotspot, which removes the baseband firmware attack surface. Even if the hotspot is compromised (many have worse security than a phone), the hotspot can only see VPN traffic.

Such a dual-device setup allows use of most mobile apps, with improved security vs a mobile phone. Still need to avoid connecting to random servers, apps, hotspots, devices and phishing emails.

wolfgke3• 10 years ago

which removes the baseband firmware attack surface.

If the baseband processor uses DMA and there exists no IOMMU that you can trust on the system, lots of evil things are possible if you can control what is sent to the mobile phone OTA.

walterbell9• 10 years ago

A wi-fi only device has no baseband processor. In lieu of an IOMMU, the baseband is delegated to a separate physical device, i.e. mobile hotspot.

A wi-fi only device is not a mobile phone, but can provide most of the functionality of a mobile phone via OTT services and VPN to a separate mobile hotspot.

kobayashi• 10 years ago

The point of the article is true, but it's also a pretty poor-quality piece. Few links to references events, and even a basic fact like the name of the company that used the Trident attack is wrong. It's the "NSO Group", not "NOS".

greglindahl• 10 years ago

It's a classic "let's make perfection the enemy of the good" headline... clickbait and unhelpful at the same time.

danjoc• 10 years ago

All they had to say was "baseband processor back doors" and drop the mic.

JoshTriplett2• 10 years ago

If you're building a phone, don't give the baseband CPU any access to anything; that's a design flaw, and you can build a phone without it. And all your data should be encrypted, so exploiting or backdooring the baseband just gives you yet another way to look at that encrypted data.

trendia• 10 years ago

Many privacy and security concerns stem from the baseband processor -- from Stingrays to completely unknowable rootkits. The only real fix is to not use a proprietary baseband processor at all, though this would mean completely rethinking the mobile phone. (say, switching to long range WiFi)

zby• 10 years ago

We need a CubesOS like system for phones.

carlesfe• 10 years ago

Forgive me if I'm wrong, but isn't that what iOS does, where every app is sandboxed and can't access anything from others?

Of course, there may be exploits derived from kernel/"supervisor" bugs, but all apps are sandboxed by default, for better or worse.

walterbell9• 10 years ago

Qubes also isolates some devices (e.g. NIC, WiFi, USB) and their drivers/firmware, using the hardware IOMMU to protect against DMA attacks by a compromised device. There is a separate threat from the Intel ME, but the threat from non-Intel devices is reduced.

pjmlp6• 10 years ago

You can still exploit memory corruption, even if the app is sandboxed.

nickpsecurity8• 10 years ago

OK Labs had one way stronger than QubesOS that's based on L4 kernels with user-mode virtualization of OS's since 2006. Same research group and company that did seL4 kernel. It was acquired by General Dynamics. OKL4 3.0 was open-source, though. So are L4Linux, OCL4, and Genode that could all be modified to recreate the OKL4 platform.

Summary of OK Labs:

https://en.wikipedia.org/wiki/Open_Kernel_Labs

Current company:

https://gdmissionsystems.com/cyber/products/trusted-computin...

Others include INTEGRITY, LynxSecure, VxWorks MILS, PikeOS... many lightweight kernels have done this. Also had real-time properties in most which helps with rooting out covert, timing channels.

Zigurd• 10 years ago

The question is not "unhackable." The question is whether it is practical for...

1. A criminal to hack in to steal money

2. A state actor to routinely hack in for surveillance

3. A state actor to penetrate a system with "on the ground" resource: a black bag job, bribes, blackmail, etc.

4. A state actor to mount a heroic effort, having to invent new technologies, in order to penetrate a system.

As long as a system can protect you from 1. and 2., it's adequate. As long as you can't do pervasive surveillance, you're safe from criminals and from "casual tyranny." Preventing pervasive surveillance doesn't mean securing the first phone from surveillance. It means making it impractical to break into and tap tens of thousands of phones undetected.

In practice, it is possible to end technology-enabled pervasive surveillance. From the East German experience with the Stasi we know the limits to scaling human surveillance. Preventing that from happening isn't a technology problem.

nickpsecurity8• 10 years ago

Ive already proven it with a risk analysis from years sgo. Some already happened. Here's a summary:

https://news.ycombinator.com/item?id=10906999

Just repost that any time someone claims their smartphone is secure. Ask what they did for each area and proof of its effectiveness.

kabdib• 10 years ago

There's a LOT that the phone OS and hardware manufacturers can do at the hardware and firmware level to make things better. A good model would be the security strategies used on game consoles, the recent generations of which have moved critical pieces of the system to embedded processors (sort of like the secure enclave on recent iPhones, but with more isolation).

Not putting device drivers written by random external engineers into the trusted part of your OS would be a good start. So would not letting any page acquire executable permissions without being signed (not sure what you do with jitted code -- if you can't effectively sandbox it, you probably don't want to run it, and yeah, that's a drag). Forbidding external processors (e.g., the radio module) from becoming physical bus masters is also a great idea. Encrypted memory (at the cache line level) has been in consoles for over a decade; it's not that expensive and it's a nice first defense against stuff like RowHammer and folks mucking with physical wires in a lab.

Consoles take this level of security seriously because it's not just about customer privacy or security or similar pesky stuff, it's about the revenue stream. (Secondarily, it's also about limiting the actions of bad actors on hardware under their control -- it's much harder to cheat on a console).

mSparks5• 10 years ago

->There's a LOT that the phone OS and hardware manufacturers can do at the hardware and firmware level to make things better.

Yeah, like not issuing phones with intentionally compromised baseband processors.

In fact, any phone that has a direct connection from the mic to the baseband processor is not just "hackable" - it's designed to hack your life (hint:all of them).

agentdrtran• 10 years ago

Any proof of this?

nickpsecurity8• 10 years ago

Part of this comes from long-standing partnerships between telecoms and intelligence agencies. Esp MI6. Ever wonder why there were protocol steps like answering without ringing ir notifying user available in user phones? Sure it was just for data collection systems in industry that happen to hack a solution out of a GSM phone. ;)

Unfortunately, many schemes were baked into the standards you certify against. Good luck changing that while reaching mass market.

jrcii2• 10 years ago

The Neo900 sandboxes the baseband, our best hope for a secure phone and last I checked they're busy arguing with PayPal to get their account back, very sad.

pjmlp6• 10 years ago

Also make use of safer systems programming languages, with unsafe code only allowed in signed binaries with controlled access.

s_q_b• 10 years ago

"The only truly secure system is one that is powered off, cast in a block of concrete and sealed in a lead-lined room with armed guards... And even then I have my doubts." [0]

For your application to be secure, hundreds of thousands of individuals must have never made a mistake in millions of LOC within libraries generally written in low-level C. That isn't very plausible.

If at some point, my input hits your code, your memory, and your processor, that fact alone is sufficient to know that the system is vulnerable.

[0] "Computer Recreations: Of Worms, Viruses and Core War" by A. K. Dewdney, Scientific American, March 1989

wtbob• 10 years ago

… generally written in low-level C …

Maybe we should focus on that? Why are we writing OSes in C when more-secure alternatives have existed for decades? Why don't we consider writing our phone OSes (which don't actually require backward-compatibility to 1960s OSes) in something higher-level and more-secure?

pjmlp6• 10 years ago

Because industry adopted an OS whose code was available for free, aka UNIX, and C came along.

Just today I read a paper fron the author of Concurrent Pascal to C.A.R. Hoare, written in the early 90's about industry's looming doom due to C's usage starting to take off outside UNIX.

He was right...

walter_bishop• 10 years ago

How about putting a hardware switch on the device such that you can't write to the non-volatile memory when the switch is in the off state. For day-to-day use the switch can be left in the off state. For software updates, set the switch to on, boot the device, update the OS, set the switch to off and reboot the device.

Why an unhackable mobile phone is a complete marketing myth

Related Stories