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.
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:
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?
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.
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.
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.
I did mean that as a comment, yes. I put that as a comment because in either of the other cases it already has a continue statement, so it wouldn't get to after the else comment unless the other conditions weren't met.
Also, you are right that I made a mistake, in that I forgot to check if a wrong next character was a correct first character and similar problems.
Oops!
Ok.
What I was trying to argue was that it is possible for a program in a Turing complete system to have no exploits, not that it is easy to write a program like that.
I thought it was being claimed that it is completely impossible to write a program with no exploits for a Turing complete machine, and I was trying to argue against that.
You're right and you communicated that point well.
I took the thread to a slight diversion given the premise that it's easy to write bugs in even short, simple code snippets, and that those bugs then introduce the requirement for maintenance, which brings in further opportunities for exploits to be introduced.
Suppose the program you gave as example doesn't have a stack. Does the TCP/IP code of the underlying operative system that would run it have one? If so, then your unexploitable program can be exploited without it even noticing, correct?
I was imagining the code (translated to some machine code version) being running on hardware.
Of course, that isn't actually necessary for the argument. It doesn't matter whether the program is running on hardware directly or through some OS, so long as the thing running it is not broken.
When one talks about a Turing machine running a program, one generally does not model the machine as occasionally not working as specified.
Similarly here, the assumption is that the implementing thing, whether it be an OS or a circuit, works according to the spec that the program for it is based around.
I see your point. Well even IBM Simon was running Datalight ROM-DOS. I can't imagine a device as complex as a smartphone, even with a fraction of its features running all directly on the metal, can you? https://en.wikipedia.org/wiki/Datalight#ROM-DOS
> can be attacked on that message until its stack dumps
This sounds like an attempt to combine intuitions about the pumping lemma with memory corruption vulnerabilities: that "any system" must have some inputs that are "too much" for it to interpret correctly (for many programs written in C, that could be a single input string that's "too long").
These intuitions are founded on good reasons because every computing system has different kinds of limitations, and some kinds of distinctions that it can't make correctly, and some kinds of failure modes if it's expected to make arbitrary distinctions.
But there are ways out:
* If we narrow the definition of the task that the system has to do, it may be possible for the system to do it perfectly, and it may even be possible to make a formal proof that the system performs that task perfectly, even though there are other more general tasks that it doesn't perform, or performs imperfectly.
* If we allow the system to "give up" or indicate that it refuses or fails to answer certain questions, then it doesn't have to be "wrong" or exhibit wrong or unpredictable behavior. It can just say "sorry, not sure", which may be annoying but isn't a mistake and isn't necessarily a security vulnerability. (Maybe this is akin to those movie robots saying "does not compute" all the time.)
Within these frameworks, a kind of perfection, or at least a kind of correctness, is possible for many computing tasks -- including some that involve Turing-completeness, either as a property of the environment they're implemented in or as a property of the machine they implement.
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.
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.
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.
"What's important is hackable by who, and in what way."
I strongly agree with this statement but my explanantion of it may be somewhat different.
Hackable means controllable.
Hack = control.
A computer, including a small form factor one called a "mobile phone", should be hackable by its user. Freedom to tinker.
A user can then, if so desired, set up and use the computer in such a way as to be less hackable by others. There is nothing more discouraging for an attacker than a highly idiosyncratic, non-standard system.
A user cannot protect a computer over which she does not have meaningful control. This is common sense. Mobile phones are just computers... with a lot of unneeded complexity. And third parties such as telecoms and search engine companies have greater control over them than users.
Trying to protect a user's computer by delegating control to a third party or combination of third parties, while denying control to the user, is an exercise in futility.
A computer that is sealed shut, with a locked bootloader and which can only use a narrow choice of OS, etc. is not hackable by its user.
It can be secured against users perhaps, but it cannot be secured in any meaningful way against third parties that truly benefits the user.
This is because the user does not have the most control over the computer.
It does not matter how much effort the user wants to make including how much money they are willing to spend in order to protect the computer because the user is not allowed to have as much control as various third parties.
A $5-$25 credit card-sized development board is easier to protect than a mobile phone.
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].
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.
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.
> 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.
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.
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.
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?
"Even isolated basebands often have a USB bridge (which can be exploited by pretending to be another type of device with a vulnerable USB driver) and direct access to the microphone ... iirc it's using a high-speed serial link, not USB. The microphone is connected to the audio codec, which is connected to the application processor. Uplink audio is sent from there to the baseband."
That's not necessarily true. Always remember that the hardware industry likes to consolidate multiple products into one for cost reduction where possible. This happens especially with embedded or mobile SOC's where a chip might have features usable in many applications at various price points. So, they make them pretend to be chips without the extra features via factory switches.
As an example, a SOC for feature phones having both GSM and WiFi might be reused in a cheaper "wifi adapter" that still has GSM circuitry but not visibly. Whether if can be used against you depends on whether it's a hard or soft switch they used to disable/hide it plus whether it's reversible or one-time (eg antifuse).
The proprietary companies already do this looking for hidden stuff. Mostly patent violations, though, so they can scheme some licensing revenue out of the product they're inspecting. Here's the company that does much of it:
In that one, you'll see the other end of the process where many mobile chips will get extremely specialized. Notice this one has several RF chips instead of an integrated one to attempt to hit some size/price/energy/performance tradeoff. Plus Apple sells premium stuff whether they can put in more, nicer parts. Notice there's 10 different chips involved in just the RF front-end part. :)
Here's a nice PDF with illustrations of the RE processes themselves plus what things look like:
I like Fig 3 especially as a lot of people forget there's circuitry inside their PCB's rather than just on top or bottom. That cell phone has 9 layers of wiring. :)
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".
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.
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)
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.
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.
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.
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.
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).
->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).
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.
Who now have nothing better to do than down vote comments like this. Like anyone important doesn't already have access to one of the thousands of black market stingray type devices that came out a couple of years ago.
The NSA and GHCQ, among others, were constantly reviewing the phone standards for use in secure products + SIGINT obviously. The were putting experienced breakers and security engineers on it, many with extensive COMSEC background. The phones their defense contractors produced had few to none of these weaknesses depending on security vs usability tradeoff. Many private suppliers, who sold to governments, did the same. The internal presentations whose details leaked in various papers around government programs and defense products also showed they consistently knew risks of transmission mediums. It's actually the only form of security they know through and through down to emissions of analog components. They mastered it decades ago with only real challenge being people wanted benefits of insecure phones. :)
Then, they not only allowed these standards but endorsed them for the general public and businesses. They also made it illegal for us to buy their Type 1-secure phones or TEMPEST-certified devices. That last part is how you go from "were they just incompetent?" to "they're deliberately keeping us insecure to enable SIGINT!" If they say it's to stop reverse engineering, then ask why the recent devices are supposed to be field releasable where enemies might pick them up but citizens of Five Eyes still can't buy them. Excuses getting thinner and thinner even if we never get some contractor leaking the proof we need from somewhere in Hawaii. ;)
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.
Looks like they are now accepting down payments via wire transfer, https://my.neo900.org. The FAQ claims they will pay 2% monthly (!) interest on down-payments, http://neo900.org/faq. Even with reuse of a Nokia N900 case/LCD, the motherboard will cost about $1K USD. The FAQ mentions baseband isolation:
"We're going to address privacy concerns of non-free modem firmware by ensuring that the modem has access to no more data than absolutely necessary, so it won't be able to spy on anything that's not already available on carrier side. On Neo900 one can be sure that the modem is actually turned off when requested, not just pretending to be. Users will be notified in case of the modem wanting to do something without their consent. Unlike some other smartphones do, Neo900 won't share system RAM with the modem and system CPU will always have full control over the microphone signal sent to the modem. You can think of it as a USB dongle connected to the PC, with you in full control over the drivers, with a virtual LED to show any modem activity."
The proposal you linked would not work if the specific USB interface was set up correctly to only allow a specific device (identified by a specific whitelisted USB device descriptor) to operate only with a specific driver. This internal USB interface in the Neo900 will allow this sort of configuration which would prevent the attack you suggest.
Sure if you plug in random USB devices via the OTG port or the pins under the battery you could attempt this attack (if security was once again loose on those ports) but hopefully your USB keyboard/mouse/flash drive or whatever you're plugging into there is less dangerous and black-box than a baseband modem. And heck, if you are still worried nothing stops you from applying the same security measures to those interfaces as well.
Pi3 + screen + 20ah lipo + mic + speaker + usb 4g modem (removable)
and linfone or equivelent.
Just need a 3d printer so i can print the case.
A bit of a brick. but a quite the "swiss army knife" of comms.
I also dont know how many people are aware just how sensitive the mic is on modern phones. I wrote a little app that turns android phones into bugs (broadcasts sound from the mic over wifi) a few years ago. It can pick up a whisper from 40m away, while when using it as a phone there is never any background noise.
"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
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?
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.
"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.
I keep posting them since he simply got so much done ahead of others. Invented monitors, nucleus concept for OS design, safe[r] concurrency, co-invented Wirth-style development of OS's (sort of drew on each other), and so on. Thing I like about his papers is he comes off like a real engineer that tried to get at the root of the problem, solve it in a systematic but practical way, avoid overcomplication, and clearly publish the solution. Yet, hardly anyone knows his name or research. I fix shit like that. :)
Wait till you get to Edison System on PDP-11 that gave us C and UNIX. He beat BCPL author and Wirth at their game of over-simplifying systems. Language was simpler than C, safer, easier to compile, and more efficient for calls between tasks. Then he did distributed system language after that. I for whatever reason haven't got around to reading those in depth but I'm sure they'll be interesting.
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!!
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!!
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.
81 comments
[ 4.6 ms ] story [ 147 ms ] threadhttps://news.ycombinator.com/item?id=11942015
If you have time, read up on the basics: http://www.erights.org/talks/promises/paper/tgc05-submitted....
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.
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.
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.
Also, you are right that I made a mistake, in that I forgot to check if a wrong next character was a correct first character and similar problems.
Oops!
Ok.
What I was trying to argue was that it is possible for a program in a Turing complete system to have no exploits, not that it is easy to write a program like that.
I thought it was being claimed that it is completely impossible to write a program with no exploits for a Turing complete machine, and I was trying to argue against that.
I took the thread to a slight diversion given the premise that it's easy to write bugs in even short, simple code snippets, and that those bugs then introduce the requirement for maintenance, which brings in further opportunities for exploits to be introduced.
Of course, that isn't actually necessary for the argument. It doesn't matter whether the program is running on hardware directly or through some OS, so long as the thing running it is not broken.
When one talks about a Turing machine running a program, one generally does not model the machine as occasionally not working as specified.
Similarly here, the assumption is that the implementing thing, whether it be an OS or a circuit, works according to the spec that the program for it is based around.
This sounds like an attempt to combine intuitions about the pumping lemma with memory corruption vulnerabilities: that "any system" must have some inputs that are "too much" for it to interpret correctly (for many programs written in C, that could be a single input string that's "too long").
https://en.wikipedia.org/wiki/Pumping_lemma
https://en.wikipedia.org/wiki/Buffer_overflow
These intuitions are founded on good reasons because every computing system has different kinds of limitations, and some kinds of distinctions that it can't make correctly, and some kinds of failure modes if it's expected to make arbitrary distinctions.
But there are ways out:
* If we narrow the definition of the task that the system has to do, it may be possible for the system to do it perfectly, and it may even be possible to make a formal proof that the system performs that task perfectly, even though there are other more general tasks that it doesn't perform, or performs imperfectly.
* If we allow the system to "give up" or indicate that it refuses or fails to answer certain questions, then it doesn't have to be "wrong" or exhibit wrong or unpredictable behavior. It can just say "sorry, not sure", which may be annoying but isn't a mistake and isn't necessarily a security vulnerability. (Maybe this is akin to those movie robots saying "does not compute" all the time.)
Within these frameworks, a kind of perfection, or at least a kind of correctness, is possible for many computing tasks -- including some that involve Turing-completeness, either as a property of the environment they're implemented in or as a property of the machine they implement.
This is false theoretically.
For example, a while loop code in a Turing Machine is unhackable; the state repeats forever.
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.
How many devices are there in the wild that have yet to be patched against stagefright? I bet it's over 50%
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...
"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
I strongly agree with this statement but my explanantion of it may be somewhat different.
Hackable means controllable.
Hack = control.
A computer, including a small form factor one called a "mobile phone", should be hackable by its user. Freedom to tinker.
A user can then, if so desired, set up and use the computer in such a way as to be less hackable by others. There is nothing more discouraging for an attacker than a highly idiosyncratic, non-standard system.
A user cannot protect a computer over which she does not have meaningful control. This is common sense. Mobile phones are just computers... with a lot of unneeded complexity. And third parties such as telecoms and search engine companies have greater control over them than users.
Trying to protect a user's computer by delegating control to a third party or combination of third parties, while denying control to the user, is an exercise in futility.
A computer that is sealed shut, with a locked bootloader and which can only use a narrow choice of OS, etc. is not hackable by its user.
It can be secured against users perhaps, but it cannot be secured in any meaningful way against third parties that truly benefits the user.
This is because the user does not have the most control over the computer.
It does not matter how much effort the user wants to make including how much money they are willing to spend in order to protect the computer because the user is not allowed to have as much control as various third parties.
A $5-$25 credit card-sized development board is easier to protect than a mobile phone.
Because it is "hackable" by it user.
[1] https://source.android.com/security/bulletin/2016-10-01.html [2] https://www.zerodium.com/program.html
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.
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.
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.
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.
Are there consumer ARM mobile devices with an IOMMU?
Unluckily I can't give any recommendations, since I myself still have to read up a lot on the whole topic. :-(
"Even isolated basebands often have a USB bridge (which can be exploited by pretending to be another type of device with a vulnerable USB driver) and direct access to the microphone ... iirc it's using a high-speed serial link, not USB. The microphone is connected to the audio codec, which is connected to the application processor. Uplink audio is sent from there to the baseband."
As an example, a SOC for feature phones having both GSM and WiFi might be reused in a cheaper "wifi adapter" that still has GSM circuitry but not visibly. Whether if can be used against you depends on whether it's a hard or soft switch they used to disable/hide it plus whether it's reversible or one-time (eg antifuse).
http://www.chipworks.com/about-chipworks/overview/blog/apple...
In that one, you'll see the other end of the process where many mobile chips will get extremely specialized. Notice this one has several RF chips instead of an integrated one to attempt to hit some size/price/energy/performance tradeoff. Plus Apple sells premium stuff whether they can put in more, nicer parts. Notice there's 10 different chips involved in just the RF front-end part. :)
Here's a nice PDF with illustrations of the RE processes themselves plus what things look like:
https://www.iacr.org/archive/ches2009/57470361/57470361.pdf
I like Fig 3 especially as a lot of people forget there's circuitry inside their PCB's rather than just on top or bottom. That cell phone has 9 layers of wiring. :)
Of course, there may be exploits derived from kernel/"supervisor" bugs, but all apps are sandboxed by default, for better or worse.
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.
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.
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.
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).
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).
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-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)
Unfortunately, many schemes were baked into the standards you certify against. Good luck changing that while reaching mass market.
http://motherboard.vice.com/read/the-black-market-dealers-se...
http://www.zdnet.com/article/invasive-phone-tracking-new-ss7...
The NSA and GHCQ, among others, were constantly reviewing the phone standards for use in secure products + SIGINT obviously. The were putting experienced breakers and security engineers on it, many with extensive COMSEC background. The phones their defense contractors produced had few to none of these weaknesses depending on security vs usability tradeoff. Many private suppliers, who sold to governments, did the same. The internal presentations whose details leaked in various papers around government programs and defense products also showed they consistently knew risks of transmission mediums. It's actually the only form of security they know through and through down to emissions of analog components. They mastered it decades ago with only real challenge being people wanted benefits of insecure phones. :)
Then, they not only allowed these standards but endorsed them for the general public and businesses. They also made it illegal for us to buy their Type 1-secure phones or TEMPEST-certified devices. That last part is how you go from "were they just incompetent?" to "they're deliberately keeping us insecure to enable SIGINT!" If they say it's to stop reverse engineering, then ask why the recent devices are supposed to be field releasable where enemies might pick them up but citizens of Five Eyes still can't buy them. Excuses getting thinner and thinner even if we never get some contractor leaking the proof we need from somewhere in Hawaii. ;)
"We're going to address privacy concerns of non-free modem firmware by ensuring that the modem has access to no more data than absolutely necessary, so it won't be able to spy on anything that's not already available on carrier side. On Neo900 one can be sure that the modem is actually turned off when requested, not just pretending to be. Users will be notified in case of the modem wanting to do something without their consent. Unlike some other smartphones do, Neo900 won't share system RAM with the modem and system CPU will always have full control over the microphone signal sent to the modem. You can think of it as a USB dongle connected to the PC, with you in full control over the drivers, with a virtual LED to show any modem activity."
It might be possible to attack the phone from the USB connection to the baseband, https://news.ycombinator.com/item?id=12673735
Sure if you plug in random USB devices via the OTG port or the pins under the battery you could attempt this attack (if security was once again loose on those ports) but hopefully your USB keyboard/mouse/flash drive or whatever you're plugging into there is less dangerous and black-box than a baseband modem. And heck, if you are still worried nothing stops you from applying the same security measures to those interfaces as well.
and linfone or equivelent.
Just need a 3d printer so i can print the case. A bit of a brick. but a quite the "swiss army knife" of comms.
I also dont know how many people are aware just how sensitive the mic is on modern phones. I wrote a little app that turns android phones into bugs (broadcasts sound from the mic over wifi) a few years ago. It can pick up a whisper from 40m away, while when using it as a phone there is never any background noise.
https://www.youtube.com/watch?v=8eaiNsFhtI8
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
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?
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...
"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
Wait till you get to Edison System on PDP-11 that gave us C and UNIX. He beat BCPL author and Wirth at their game of over-simplifying systems. Language was simpler than C, safer, easier to compile, and more efficient for calls between tasks. Then he did distributed system language after that. I for whatever reason haven't got around to reading those in depth but I'm sure they'll be interesting.