For starters, let's see what "pod2g" has to say:
So the problem appears to be at an operating system level, in how iOS parses through an incoming SMS packet. It's worth noting that this is the actual carrier-based Short Message Service protocol, not Apple's own iMessage protocol -- which, we assume is not affected by this bug.In the text payload, a section called UDH (User Data Header) is optional but defines lot of advanced features not all mobiles are compatible with. One of these options enables the user to change the reply address of the text. If the destination mobile is compatible with it, and if the receiver tries to answer to the text, he will not respond to the original number, but to the specified one.Most carriers don't check this part of the message, which means one can write whatever he wants in this section : a special number like 911, or the number of somebody else.In a good implementation of this feature, the receiver would see the original phone number and the reply-to one. On iPhone, when you see the message, it seems to come from the reply-to number, and you loose track of the origin.
Since the problem is at an operating system level, it's not likely that there are any publicly accessible APIs where we need to worry about this in our own apps. But does that mean it's not an issue for our apps? Not entirely.
Many apps (e.g., Google, Facebook) these days use SMS as an out-of-band authentication mechanism to verify our users are who they say they are. If your app uses this, you should be aware that an attacker could conceivably send a spoofed validation code to your users. An attacker could also spam your users making the messages appear to be from your own app's "caller ID" or phone number.
For that matter, if you're using SMS for other things -- perhaps contacting your users to let them know about updates or some such -- it's worth knowing that an attacker could spoof your messages. (And you really should be using the built in notification service in any case.)
Does that matter to your app? More to the point: is there anything you should be doing about this problem right now? In the grand scheme of things, we don't think so. We'll go ahead and file that under "good to know, but there's not much we need to do about it today -- and hope that Apple fixes this input validation problem in their next iOS release."
Ken van Wyk