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.
