11 ms·

Why an unhackable mobile phone is a complete marketing myth

67 points by sidcool 10y ago

sebastianconcpt 10y 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 10y ago
  Could you post that Ethereum problem as a story and/or comment? Curious to read it
  - hueving 10y ago
    I'm guessing op is just referring to the DAO disaster.
    - sebastianconcpt 10y ago
      Yes I was referring to the DAO disaster. Here are some interesting discussions about it https://www.reddit.com/r/btc/comments/4p0gq3/why_turingcomplete_smart_contracts_are_doomed/ https://www.reddit.com/r/btc/comments/4p0gq3/why_turingcompl...
      - schoen 10y ago
        It would be safer in many of these ways to prefer non-Turing-complete smart contracts -- and non-Turing-complete software environments in general for many tasks -- but I think formal undecidability is something of a red herring here because not all programs' behavior is undecidable. My previous comments on this issue in this context: https://news.ycombinator.com/item?id=11942015 https://news.ycombinator.com/item?id=11942015
  - feklar 10y ago
    This also explained it well, predicting contracts would be full of problems http://vessenes.com/ethereum-contracts-are-going-to-be-candy-for-hackers/ http://vessenes.com/ethereum-contracts-are-going-to-be-candy...
- mynameislegion 10y 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 https://twitter.com/zooko/status/748683889934163969 If you have time, read up on the basics: http://www.erights.org/talks/promises/paper/tgc05-submitted.pdf http://www.erights.org/talks/promises/paper/tgc05-submitted....
- drdeca 10y 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.
  - sebastianconcpt 10y 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.
    - drdeca 10y ago
      Its stack? Just because it is Turing complete does not imply that it uses a stack. Consider: look_for := "some string"; n := len(look_for); send_out := "other string"; i := 0; while(true){ c=getInputChar(); if(c==None){ i=0; continue; } if(c==look_for[i]) { i+=1; continue; } if(i==n){ output(send_out); i=0; continue; } //else i=0; continue; } (Pseudo code. No specific language intended.) I see no reason that the above would require a stack (provided that the input and output features are hardware built ins rather than function calls. Just reading or writing from/to a pair of registers.) I see no way that such a program could be exploited (short of flaws in the machine). Causing the stack to dump wouldn't work, as it has no stack. It just cycles through a small number of states based on input. Now, some other program which is much more complicated could be written for the same machine, as the machine is Turing complete, but this particular program would not be vulnerable.
      - sokoloff 10y ago
        If I send that code "some some string" or "ssome string", it fails to respond with "other string" due to a bug. If I send it "sssome string", it does work. (depending on how you interpret the // before the else; if that comments out the else, then brute forcing the input by cycling all characters on the input will eventually cause output.) So, there's a bug and now a maintainer has to go in and patch the bug, which may introduce a security flaw (either in the coding or the release deployment process). You also have the exposure of whatever getInputChar() and output() do internally. I'm not arguing there is an exploit just because of using Turing complete system, but observing that even simple systems tend to have bugs and get maintenance over time.
- witty_username 10y ago
  > As long as you have Turing Complete machines you made theoretical hack possible. This is false theoretically.
  - sebastianconcpt 10y ago
    Why? Can you elaborate on demonstrating that is false?
    - alasdair_ 10y ago
      It's possible to write a program that is provably correct, so simply because a turing machine exists, doesn't mean that the Turing machine itself makes something hackable.
    - witty_username 10y ago
      Hacks occur to due bugs in software. Theoretically, one could write bug-free software. Practically, this is very hard for any non-trivial software. For example, a while loop code in a Turing Machine is unhackable; the state repeats forever.
ufmace 10y 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 10y 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%
- ufmace 10y 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_Jsmc8S5fAbRB3s4RmTG_PFnw/edit https://docs.google.com/document/d/1tHElG04AJR5OR2Ex-m_Jsmc8...
deleted 10y ago
[deleted]
walterbell 10y 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.
- wolfgke 10y 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.
  - walterbell 10y 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.
    - wolfgke 10y ago
      OK, I admit: for WiFi it is not called "baseband", but something like "WiFi chip", but the functionality is the same (just for WiFi instead of, say, UMTS or LTE) - it also runs a hidden, probably bugged, firmware.
      - walterbell 10y ago
        Thanks. Do you recommend any references on the relative difficulty of attacking WiFi radios vs. cellular radios? E.g could any local wifi access point (including a compromised mobile hotspot) attack the wifi device with some kind of magic "packet"? Are there consumer ARM mobile devices with an IOMMU?
kobayashi 10y 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 10y ago
  It's a classic "let's make perfection the enemy of the good" headline... clickbait and unhelpful at the same time.
danjoc 10y ago
All they had to say was "baseband processor back doors" and drop the mic.
- JoshTriplett 10y 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 10y 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)
    - JoshTriplett 10y ago
      You wouldn't need to switch technologies to go open; several groups have projects to develop Open Source modem firmware (and hardware, eventually).
zby 10y ago
We need a CubesOS like system for phones.
- carlesfe 10y 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.
  - walterbell 10y 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.
  - pjmlp 10y ago
    You can still exploit memory corruption, even if the app is sandboxed.
- nickpsecurity 10y 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 https://en.wikipedia.org/wiki/Open_Kernel_Labs Current company: https://gdmissionsystems.com/cyber/products/trusted-computing-cross-domain/microvisor-products/#4 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 10y 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.
nickpsecurity 10y 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 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 10y 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).
- mSparks 10y 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 10y ago
    Any proof of this?
    - mSparks 10y ago
      https://en.wikipedia.org/wiki/Stingray_phone_tracker https://en.wikipedia.org/wiki/Stingray_phone_tracker They basically give external control to all the baseband processors functions (read mic, control signal, read gps chip etc.) It's why snowden made: https://www.wired.com/2016/07/snowden-designs-device-warn-iphones-radio-snitches/ https://www.wired.com/2016/07/snowden-designs-device-warn-ip... because if your phone is in airplane mode, it shouldn't be transmitting - and they can all be made to. (Oh, and I have friends who served in Afghanistan, so found out about all this around 2002)
deleted 10y ago
[deleted]
s_q_b 10y 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 10y 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?
  - pjmlp 10y 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...
    - nickpsecurity 10y ago
      Which Hansen paper was that?
      - pjmlp 10y ago
        His remark written in 1993 is: "The 1980s will probably be remembered as the decade in which programmers took a gigantic step backwards by switching from secure Pascal-like languages to insecure C-like languages. I have no rational explanation for this trend. But it seems to me that if computer programmers cannot even agree that security is an essential requirement of any programming language, then we have not yet established a discipline of computing based on commonly accepted principles." It was written on "Per Brinch Hansen (letter to C.A.R. Hoare 1993a", however I got the quote from "Java's Insecure Parallelism" and so far failed to find a copy of his letter. I have spend the day going through his papers after you posted them, and now Solo with Concurrent Pascal, done in a PDP-11/45 is yet another proof I can refer to for safer alternatives done in about the same age C was coming to life. EDIT: Typos
deleted 10y ago
[deleted]
micro_softy 10y ago
On the notion of "unhackable" I commented here: https://news.ycombinator.com/item?id=12671744 https://news.ycombinator.com/item?id=12671744
gabby92 10y ago
Do you require the services of a hacker?..contact leehacks92@gmail.com for your ethical and unethical hacks,he's time conscious,very discreet and reliable,he’s the best i’ve worked with so far..check him out and you won't be disappointed..serious enquiries only!!
gabby92 10y ago
Do you require the services of a hacker?..contact leehacks92@gmail.com for your ethical and unethical hacks,he's time conscious,very discreet and reliable,he’s the best i’ve worked with so far..check him out and you won't be disappointed..serious enquiries only!!
walter_bishop 10y 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.

67 points by sidcool 10y 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 10y ago
Could you post that Ethereum problem as a story and/or comment? Curious to read it
- hueving 10y ago
  I'm guessing op is just referring to the DAO disaster.
  - sebastianconcpt 10y ago
    Yes I was referring to the DAO disaster. Here are some interesting discussions about it https://www.reddit.com/r/btc/comments/4p0gq3/why_turingcomplete_smart_contracts_are_doomed/ https://www.reddit.com/r/btc/comments/4p0gq3/why_turingcompl...
    - schoen 10y ago
      It would be safer in many of these ways to prefer non-Turing-complete smart contracts -- and non-Turing-complete software environments in general for many tasks -- but I think formal undecidability is something of a red herring here because not all programs' behavior is undecidable. My previous comments on this issue in this context: https://news.ycombinator.com/item?id=11942015 https://news.ycombinator.com/item?id=11942015
- feklar 10y ago
  This also explained it well, predicting contracts would be full of problems http://vessenes.com/ethereum-contracts-are-going-to-be-candy-for-hackers/ http://vessenes.com/ethereum-contracts-are-going-to-be-candy...
mynameislegion 10y 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 https://twitter.com/zooko/status/748683889934163969 If you have time, read up on the basics: http://www.erights.org/talks/promises/paper/tgc05-submitted.pdf http://www.erights.org/talks/promises/paper/tgc05-submitted....
drdeca 10y 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.
- sebastianconcpt 10y 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.
  - drdeca 10y ago
    Its stack? Just because it is Turing complete does not imply that it uses a stack. Consider: look_for := "some string"; n := len(look_for); send_out := "other string"; i := 0; while(true){ c=getInputChar(); if(c==None){ i=0; continue; } if(c==look_for[i]) { i+=1; continue; } if(i==n){ output(send_out); i=0; continue; } //else i=0; continue; } (Pseudo code. No specific language intended.) I see no reason that the above would require a stack (provided that the input and output features are hardware built ins rather than function calls. Just reading or writing from/to a pair of registers.) I see no way that such a program could be exploited (short of flaws in the machine). Causing the stack to dump wouldn't work, as it has no stack. It just cycles through a small number of states based on input. Now, some other program which is much more complicated could be written for the same machine, as the machine is Turing complete, but this particular program would not be vulnerable.
    - sokoloff 10y ago
      If I send that code "some some string" or "ssome string", it fails to respond with "other string" due to a bug. If I send it "sssome string", it does work. (depending on how you interpret the // before the else; if that comments out the else, then brute forcing the input by cycling all characters on the input will eventually cause output.) So, there's a bug and now a maintainer has to go in and patch the bug, which may introduce a security flaw (either in the coding or the release deployment process). You also have the exposure of whatever getInputChar() and output() do internally. I'm not arguing there is an exploit just because of using Turing complete system, but observing that even simple systems tend to have bugs and get maintenance over time.
witty_username 10y ago
> As long as you have Turing Complete machines you made theoretical hack possible. This is false theoretically.
- sebastianconcpt 10y ago
  Why? Can you elaborate on demonstrating that is false?
  - alasdair_ 10y ago
    It's possible to write a program that is provably correct, so simply because a turing machine exists, doesn't mean that the Turing machine itself makes something hackable.
  - witty_username 10y ago
    Hacks occur to due bugs in software. Theoretically, one could write bug-free software. Practically, this is very hard for any non-trivial software. For example, a while loop code in a Turing Machine is unhackable; the state repeats forever.

ufmace 10y 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 10y 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%
ufmace 10y 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_Jsmc8S5fAbRB3s4RmTG_PFnw/edit https://docs.google.com/document/d/1tHElG04AJR5OR2Ex-m_Jsmc8...

deleted 10y ago

[deleted]

walterbell 10y 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.

wolfgke 10y 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.
- walterbell 10y 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.
  - wolfgke 10y ago
    OK, I admit: for WiFi it is not called "baseband", but something like "WiFi chip", but the functionality is the same (just for WiFi instead of, say, UMTS or LTE) - it also runs a hidden, probably bugged, firmware.
    - walterbell 10y ago
      Thanks. Do you recommend any references on the relative difficulty of attacking WiFi radios vs. cellular radios? E.g could any local wifi access point (including a compromised mobile hotspot) attack the wifi device with some kind of magic "packet"? Are there consumer ARM mobile devices with an IOMMU?

kobayashi 10y 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 10y ago
It's a classic "let's make perfection the enemy of the good" headline... clickbait and unhelpful at the same time.

danjoc 10y ago

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

JoshTriplett 10y 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 10y 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)
  - JoshTriplett 10y ago
    You wouldn't need to switch technologies to go open; several groups have projects to develop Open Source modem firmware (and hardware, eventually).

zby 10y ago

We need a CubesOS like system for phones.

carlesfe 10y 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.
- walterbell 10y 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.
- pjmlp 10y ago
  You can still exploit memory corruption, even if the app is sandboxed.
nickpsecurity 10y 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 https://en.wikipedia.org/wiki/Open_Kernel_Labs Current company: https://gdmissionsystems.com/cyber/products/trusted-computing-cross-domain/microvisor-products/#4 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 10y 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.

nickpsecurity 10y 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 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 10y 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).

mSparks 10y 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 10y ago
  Any proof of this?
  - mSparks 10y ago
    https://en.wikipedia.org/wiki/Stingray_phone_tracker https://en.wikipedia.org/wiki/Stingray_phone_tracker They basically give external control to all the baseband processors functions (read mic, control signal, read gps chip etc.) It's why snowden made: https://www.wired.com/2016/07/snowden-designs-device-warn-iphones-radio-snitches/ https://www.wired.com/2016/07/snowden-designs-device-warn-ip... because if your phone is in airplane mode, it shouldn't be transmitting - and they can all be made to. (Oh, and I have friends who served in Afghanistan, so found out about all this around 2002)

deleted 10y ago

[deleted]

s_q_b 10y 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 10y 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?
- pjmlp 10y 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...
  - nickpsecurity 10y ago
    Which Hansen paper was that?
    - pjmlp 10y ago
      His remark written in 1993 is: "The 1980s will probably be remembered as the decade in which programmers took a gigantic step backwards by switching from secure Pascal-like languages to insecure C-like languages. I have no rational explanation for this trend. But it seems to me that if computer programmers cannot even agree that security is an essential requirement of any programming language, then we have not yet established a discipline of computing based on commonly accepted principles." It was written on "Per Brinch Hansen (letter to C.A.R. Hoare 1993a", however I got the quote from "Java's Insecure Parallelism" and so far failed to find a copy of his letter. I have spend the day going through his papers after you posted them, and now Solo with Concurrent Pascal, done in a PDP-11/45 is yet another proof I can refer to for safer alternatives done in about the same age C was coming to life. EDIT: Typos

deleted 10y ago

[deleted]

micro_softy 10y ago

On the notion of "unhackable" I commented here: https://news.ycombinator.com/item?id=12671744 https://news.ycombinator.com/item?id=12671744

gabby92 10y ago

Do you require the services of a hacker?..contact leehacks92@gmail.com for your ethical and unethical hacks,he's time conscious,very discreet and reliable,he’s the best i’ve worked with so far..check him out and you won't be disappointed..serious enquiries only!!

gabby92 10y ago

walter_bishop 10y 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.