We recently chatted with security expert Charlie Miller from Independent Security Evaluators about the recently-disclosed iPhone vulnerability that would have allowed a malicious hacker to take control of an iPhone through a series of carefully crafted SMS messages.
Alan: Thanks for taking the time to chat, Charlie. Why don’t you start by telling us a little bit about the SMS vulnerability?
Charlie: The iPhone bug has to do with telling the phone there is a certain amount of data, and then not sending it as much as you said you would. The function that reads the data starts returning -1 to indicate an error, but the other parts of the program don't check for this error and actually think the -1 is data from the message. This shows how complex it can be to write secure code, as separately, each part of the program looks correct, but the way they interact is dangerous!
Anyway, depending on what you send, different bad things can happen. At one point, you can get it to exit because it is about to allocate -1 bytes (which is viewed as 0xffffffff--a very large number). This is a denial of service that will knock the phone off the network temporarily.
During my BlackHat talk, we kept sending this denial of service message every 10 seconds to a volunteer from the audience to keep him off the network. As an unfortunate consequence, the messages were getting cued up on the network and his phone was still getting knocked off hours after the talk. He has since gotten back up and running.
Alan: Note to our readers: whenever Charlie says he needs a volunteer, don’t make eye contact. So, how did you send the message? Were you sending it through the SMS interface of another iPhone or doing something like emailing the “telephone number@attwireless” approach?
Charlie: To send the SMS over the carrier network, we had a small application on our attack iPhone that would talk to the modem using GSM AT commands. For testing and finding the bugs, we used this really cool injection framework that my co-presenter Collin Mulliner wrote, which lets you test SMS message implementations by only sending data over TCP. This prevents you from having to send data over the carrier network and doesn't cost anything, and also lets you test many messages very quickly.
Alan: So how do you go from a denial-of-service to a full-on exploit?
Charlie: The worst case has to do with how the program handles concatenated messages. This is a way to send more than 140 bytes at a time. You can send a long message in a series of messages and the phone will reconstruct it into a one long string. It accesses an array based on a value from the data. In the case where it thinks it reads -1, it actually accesses the memory before the array, not in the array. By setting things up just right and being tricky, you can actually leverage this to gain complete control of the device.
The entire attack takes just over 500 messages, although the victim doesn't know they are being sent because they don't show up on the phone. Most of these messages have to do with setting things up "just right." Sixteen of them actually access the array out of bounds.

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).
Chuck Norris doesn't use a phone, he uses his "outside" voice!
Seriously, no offense but I though mobile phone exploits were nothing new.
lol
and of course "jailbroken" iphones couldn't take down a network, how stupid must ppl really be to believe Apple/AT&Ts shit
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.
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.
Thanks,
UNIX is an OS standard developed in the 70s
Linux and OSX are both based on UNIX, therefore:
Both must have equally good security, and:
It doesn't matter how much OSX's developers suck, because if they screwed anything up, it wouldn't be UNIX anymore, because UNIX is perfect and unhackable.
If I'm not mistaken, isn't Charlie Miller(subject of this interview) a hacker famous for pwning OSX? Do any of his exploits ever work on Linux? Hasn't he been quoted as saying that Linux and Windows are both much harder to hack than OSX? Isn't Apple's uber-shi.t Safari browser a liability in itself?
Apple's QA should have done this, this is similar to a Soak test, QA's bread and butter.
oh and i'm sorry, what? "I can't fault them too much, it was hard to find". yes it would be hard to find, but to call it in the first place and not check the return type? to code it in such a way that it will only work if there is no error in the SMS (expected size == actual size).
If i was worried about security at all, I would NOT buy a device coded like this. trusting a hardware buffer overrun protection system to handle all your problems? just pathetic!
Good to see him call BS on the apple jailbreak argument!
while I bet apple was all too happy to take his advice on how to patch the iphone, they will just ignore him on this point.
"...but Linux has done by far the best job of idiot-proofing an OS..."
Yes, typing "tar zxvf blahblahblah-1.1-x86.gz cd /usr/bin/blah" is so "idiot-proof" that everyone will be doing it.
Epic fail.
It seems that you have never been to a Mac developer conference. I only bother to make that observation because the comment about "trend-setting hipsters" in reference to Apple's Mac OS team is so comical. It might be true about marketing people at Apple but it was easy to observe that as the api level got lower, the engineer from Apple got larger (wider rather than taller) and more disheveled. [Obviously being a trend-setting hipster was not a criterion for choosing personnel]. Any technology company that has been a significant player for well over thirty years is going to have its ups and downs but it is absurd to dismiss its engineering bona fides.