Exclusive Interview: Hacking The iPhone Through SMS

AT&T Full Of It? Say It Ain't So

Alan: Oh, tell me about the Windows Mobile and Android SMS issues.

Charlie: Collin's framework also works on Android and WinMobile. We found some denial of service bugs in Android (which we reported and are fixed) and a pretty bad bug in the way HTC WinMobile phones handle SMS messages containing the format specifier %n. That's a fun one because you don't need any special tools to send the malicious message, just use your phone to text your buddy with %n and their TouchFlo (application manager) will crash and won't come back up.

Alan: Readers? Please use that information for good, not evil. Does the ARM CPU in the iPhone have any sort of NX-bit type security to minimize the risk of buffer overflow exploits?

Charlie: Yes, ARM has the XN (eXecute Never) bit which plays an analogous role to NX in x86. On iPhone, this bit is set on the heap and stack. In fact, you cannot turn off this bit on heap pages, even if you try. I also gave a separate talk at BlackHat about how to circumvent this memory protection in iPhone 2.2.1 and earlier, but they fixed it in 3.0 and I don't know how to get around it at the moment.

Alan: But in this case, it was really an error in the way messages were concatenated as opposed to a traditional buffer overflow.

Charlie: Yes, there are two parts of any exploit. One is the bug, in this case, being able to access before an array in memory. The other is what do you do with this bug. This is where memory protections come into play. With no memory protections, you just put executable byte code in memory and execute it. For iPhone 3, you cannot do that and have to do something different.

This bug wasn’t a traditional buffer overflow, but was still in the class of memory corruption bugs. Programmers (and code auditors) are pretty good at looking for strcpy’s and memcpy’s. However, things can still go wrong anytime you’re dealing with pointers. In this case, by accessing an array out of bounds, an attacker can corrupt memory, just like they would in a traditional buffer overflow.

As an aside, Android implemented their SMS stack with Java. Therefore, it was not possible to corrupt memory, instead, we just got unhandled exceptions. So our attacks were limited to denial of service.

Alan: Apple and AT&T have claimed that "Jailbreaking" could cause problems with the ECID? Based upon your knowledge of the iPhone, do you believe this to be true?

Charlie: No, this is AT&T trying to make sure they make as much money as possible. Absolute FUD.

Alan: What about the claim that a jailbroken iPhone could crash cell phone towers--has anyone ever looked at the security of the software running cell phone towers?

Charlie: This is complete BS. You can diff a jailbroken kernel with a standard iPhone kernel and there are very few places that are changed. In particular, it doesn't mess with anything that has to do with the communication with the carrier. Even if it did do something crazy, which it doesn't, I would hope that the towers are robust enough to handle it. Just as the software in the iPhone should be able to handle any type of input it receives, the cell towers should too. I hope the carriers adequately test their equipment. If not, they can always give me a call, I'd be happy to help. In other words, if all it takes for a terrorist to take down cellular communication in this country is have a jailbroken iPhone, we’re in trouble.

As an aside, that was another reason I liked the injection method of testing SMS messages locally. I think if I fuzzed the phone using the carrier network, I probably would have crashed something. Even though it would be unintended, I could see them throwing me in jail for that, and that’s one place I don't want to visit!

Alan: Heh, unless you were testing the security of some new-fangled electronic security system there. I’ve seen enough Hollywood movies!  As always, thanks for taking the time to chat.

Charlie: No problem, thanks for having me again.

  • burnley14
    Wow, don't make Charlie angry. He can take over your phone remotely and kill you with it.
  • ethaniel
    Unless he hacks Chuck Norris's iPhone. That would be the end of him. :P
  • ossie
    As usual, mr. Charlie "no more free bugs" just likes to overemphasize his findings - free advertising is always great - but it seems his greediness isn't finding the proper nourishment (read cash from blackmailed manufacturers).
    Crashing an equipment is one thing (getting easier in these days of consumerism induced fast paced "innovation"), but taking it over is in a whole different lot.
    Why didn't he demo the iPhone takeover code at BH? I'm sure he would have liked to really impress the audience, but, as it needs a lot of very careful setup, the chances for failure would have been way too high. There are a lot of unexpected events which could have taken place in a real environment (read through the network), as opposed to a laboratory environment (frame injection without external disturbance), which would impede the "golden sequence" to reach it's victim in the desired way (out of order message delivery is just one, which comes quickly to mind).
  • downer88
    ethanielUnless he hacks Chuck Norris's iPhone. That would be the end of him.Chuck Norris doesn't use a phone, he uses his "outside" voice!

    Seriously, no offense but I though mobile phone exploits were nothing new.
  • This should be considered a nice and very credible rebuttal to the ridiculous interview with Joanna Rutkowska... Charlie is a real security expert, and he says Mac security sucks. Take note, Apple fanboys.
  • steiner666
    downer88Chuck Norris doesn't use a phone, he uses his "outside" voice!

    and of course "jailbroken" iphones couldn't take down a network, how stupid must ppl really be to believe Apple/AT&Ts shit
  • anonymousdude
    Charlie_FangirlThis should be considered a nice and very credible rebuttal to the ridiculous interview with Joanna Rutkowska... Charlie is a real security expert, and he says Mac security sucks. Take note, Apple fanboys.
    The safety of a Mac lies in its market share. Less market share less atacks,viruses,trojans, etc. That's why people using linux hardly ever have a problem with security.
  • anonymousdude: Linux has all but idiot-proof security, low-level exploits are very difficult, there are package repositories that have everything you could ever need without resorting to potentially untrustworthy 3rd party downloads, and they were doing Microsoft's UAC long before Microsoft, and far better and less annoying. Not to mention, they have a far better scheme for handling execute bits and possible remote execution of arbitrary code. An OS is only as good as the idiot who's using it, but Linux has done by far the best job of idiot-proofing an OS, if it hits 99% marketshare, it will still have a fraction of the problems Windows and OSX do, and there are viruses for OSX, ask Apple who recommend MULTIPLE antiviruses be installed on Macs. Out of tens of thousands of free, open source Linux packages, there are hardly any antiviruses or firewalls even available for Linux, because it is actually for real, not necessary. No shit...

  • @synonymousdude,

    OS X is built on UNIX the same as Linux. Please do some research before you spout about things you obviously no nothing about. Otherwise quite wasting the time of everyone that reads the comments.

  • rorosdad: Obviously you know nothing about UNIX or Linux or the inner-workings of OSX. UNIX operating systems follow a standard called POSIX. There is quite a bit of room for differences in how they are implemented. The BSD kernel OSX stole is not the same kernel that Linux uses, besides, most of the security doesn't necessarily happen in the kernel, user interaction happens in the desktop and window managers. Is there package managers for OSX like Synaptic or Adept? Is anybody at Apple smart enough to thwart low-level exploits, or do they only hire "trend-settings hipsters" to be developers? You obviously don't know much about OSes, maybe you should try to educate yourself before acting defiant to me.