Explaining The Vulnerability, Continued
Alan: What about push notifications and visual voicemail? Don’t those rely on SMS?
Charlie: Not sure about the push notifications, although that would make sense. It does use SMS to alert when new voice mail arrives, as well as indicating where the phone can pick up the actual sound files. It also uses SMS as notification of MMS messages.
Alan: So potentially, the push notifications or new voicemail arrival have “magic strings?" Couldn’t a malicious hacker direct the iPhone to pick up a forged voice mail with sound files from somewhere else?
Charlie: It is not that they have magic strings, but rather that SMS is more than text messages. It can be used to transfer data as well. Some carriers use it to send ringtones and OTA updates, for example. There is a byte in the header in the data that tells the device what kind of data it is, and the device knows how to handle different kinds of data. The concatenated messages I spoke of earlier have this “identifier” byte set to 00. Normal text messages don’t even have this data header. Another type of data indicates the number of voice mails that are waiting. Finally, a different type of data (one destined for a particular SMS “port”) tells the phone where to get the sound file. This also explains why I can send 500 messages and you don’t know about it. They are all “data” SMS messages and so your phone doesn’t display them to you since they are not simple text messages.
Many people wanted to know how to disable SMS when this bug came out. In most cases, you cannot disable them because SMS is a core feature of the phone, and the carriers rely on it for much of the functionality you depend on.
For testing, I tried to have the iPhone pick up a sound file from my Web server, but apparently the AT&T infrastructure will only allow it to pick up this file from their servers.
Alan: In your opinion, had Apple audited the code for security, should they have caught the bug?
Charlie: Umm...bugs are hard to find, which is why people pay me to look for them. This bug wasn't obvious by any means, and it was the only one I found while performing a moderate fuzzing effort, so I guess I can't fault them too much.
Alan: Seems like there are themes to security though. Programmers get trained to think about the boundary cases when debugging or malformed user input, but I think a lesson learned here is that the interaction between different modules is important to consider. What’s been the reception to your “No Free Bugs” campaign?
Charlie: Mostly silence. Some people have written with support, but mostly no one talks about it. It’s probably mostly my fault because I'm terrible at organizing things, and I am very busy with work and research, so haven't put any time in it. I still think if vendors paid, more people would look for bugs. This SMS stuff is a good example. Between us, Collin and I found one bug in iPhone, Android, and Windows Mobile. Then we stopped testing. We had enough for our talk, what motivation did we have to keep looking? This is really an unpaid hobby for us, so we do the minimum level of work possible to get results good enough for conference presentations. If researchers were going to get paid big bucks for these bugs, they would look and find them.
As another example, I'm not looking at SMS bugs anymore, I'm moving on. That is what researchers do now. Why would I keep looking for these extremely dangerous bugs? I won’t get paid and since there were a rash of SMS talks at BlackHat, conferences won’t be interested in them for a while. That is really what “No More Free Bugs” is about--motivating skilled researchers to look for bugs. Bad guys are already motivated by the financial gains they stand to make and will continue looking for these powerful bugs.
