OP here. In short, it sounds like the iPhone SMS infrastructure is susceptible to buffer overflow attacks. Seems the guys who have found it have given Apple a lot of time to fix it with no response so far.
Though Miller and Mulliner say they notified Apple about the vulnerability more than a month ago, the company hasn't released a patch, and it didn't respond to Forbes' repeated calls seeking comment.
those new android phones are coming out later this year, right?
This makes me wonder if the reason we haven't seen major threats on other mobile devices/platforms is due more to the lack of a market penetration vs. a lack of security.
It's the old 'Apple doesn't get viruses' argument in reverse. Not as many viruses targeted Macs because it had a smaller user base, so they focused on Windows. Now that Apple has serious traction with a device which is in someways ideally suited to forwarding the virus, they are becoming the focus on an attack.
This was reported earlier in the month. Most blogs' source reference is this Yahoo Tech article, that claims:
"Apple is working to fix an iPhone vulnerability that could allow an attacker to remotely install and run unsigned software code with root access to the phone."
No details on if Apple dropped the ball or if they were actually working on it in the first place.
My best guess to the vulnerability is the iPhones new MMS capability. They probably had to punch some holes in the sandbox to get MMS media saved on to the phone.
Seems like a reasonable guess, but I still don't see where the widespread capability for hijacking the phone would come from. For that there would seem to be a requirement to launch and concurrently run an application permanently...and, unless I'm missing something, such an approach is inherently quite difficult and (intentionally) limited on the current iPhone OS.
The phone is perfectly capable of running background processes -- it really is just Darwin running on a small ARM device.
The default sandbox does not permit calls to fork/exec, but there's no guarantee that the SMS application runs in that sandbox, or that an attacker can't find a way to escape the sandbox.
The language doesn't really matter. Here are the problems that C introduces, and how other languages have solved them:
Buffer overflows. The solution is to not let the programmer (or attacker, when exploited) touch arbitrary memory. All the "managed" environments do this. ("But what if there's a bug in the implementation!?" Well, fix that, and you've fixed all existing software and all future software. Much better than checking every program for the same bug, for The Rest Of Eternity.)
Integer overflows. The solution is a better type system. Instead of overflowing, switch from the machine integer to a bigger integral type. (Yup, you lose performance after the switchover, but that's better than letting an attacker take over your machine. Optimize for speed after your program works correctly.)
Ignoring errors. Many C programmers forget to check for errors, and then the program state is silently corrupted, leading to security problems, strange behavior, etc. Exceptions solve this problem.
There are many other security problems, but these still keep cropping up even though we have tools that eliminate them. So they are most annoying to me. (Everyone has written "allow_login if !$password->valid", and I doubt new programming languages will fix that. But there is no excuse for buffer or integer overflows these days.)
Writing application software in C is the classic example of premature optimization and the evil it brings.
I agree with what you're saying about the problems that C has (or rather the problems people have with writing safe and secure C code), but I do think the language matters; just from the perspective of having any hopes of being adopted.
C is largely immune from all the language wars, because it's everyone's reference point. I think it will be very difficult to get enough people to sign off on another language for systems development. Everyone thinks they know what everyone else should use; and it makes for a very fractious environment with regards to what languages should get used... C# and Objective-C are good examples of that.
If you have a vulnerability that could result in the takeover of every iPhone in the world, along with a noticable increase in SMS message traffic over carrier networks, and the manufacturer has not fixed it yet...
... then you probably shouldn't release it.
(Also: Buffer Overflow? Hello? Did someone develop this ten years ago?)
If you have a vulnerability that could result in the takeover of every iPhone in the world, along with a noticable increase in SMS message traffic over carrier networks, and the manufacturer has not fixed it yet...
Looking at how Apple behaves in the market, I'd say that it might provide just the market correction that they need.
(Also: Buffer Overflow? Hello? Did someone develop this ten years ago?)
Apple's clear strategy is to bolt on traditional "managed runtime" features to the existing low-level languages, and their technical groups have a large standing investment in C development experience. Quite a bit of code is still written in C and occasionally C++, interfacing with Objective-C.
Whereas everyone else is clearly pushing for managed runtimes, Apple is expending considerable effort to bolt GC, closures, etc onto C. I don't think it will play out well for them.
Looking at how Apple behaves in the market, I'd say that it might provide just the market correction that they need.
I'm more interested in not having my iPhone hacked and not having lots of support calls from customers who have had theirs hacked than whether Apple gets whatever comeuppance you/he decides they deserve.
Quite a bit of code is still written in C
C does not equal 'buffer overflows'. Mistakes in C mean buffer overflows.
I'm more interested in not having my iPhone hacked and not having lots of support calls from customers who have had theirs hacked than whether Apple gets whatever comeuppance you/he decides they deserve.
Whatever comeuppance the market decides Apple deserves after they've failed to adequately serve consumers (or not, depending on the consumer's opinions).
Apple created the vulnerability, and then left it unpatched for an extended period of time. It's Apple's responsibility to not produce vulnerable software, and it's their responsibility to fix software that is vulnerable. They should be held accountable.
C does not equal 'buffer overflows'. Mistakes in C mean buffer overflows.
Humans mean mistakes, ergo, C equals 'buffer overflows' (or NULL dereferences, or format string vulnerabilities, or integer overflows, or ...).
They probably aren't the only ones who have figured it out, as the recent Anti-Sec people are making very clear. Making it public forces it to get fixed so that nobody can use it, instead of only the Russian Business Network being able to use it.
This is a defect in the product which could substantially harm the users of the product. The people who know about the defect have a moral obligation to inform the people who are at risk, and to give those people adequate information to verify that the defect really exists.
It's also worth noting that Apple has imposed technical measures which attempt to prevent iPhone users from correcting this defect on their own iPhones, even if they know where it is. I think they also claim that copyright law prohibits those users from correcting the defect. Under these circumstances, Apple and the attacker ought to be jointly liable for any damages caused by an attacker exploiting the flaw.
All you need to do is infect a few phones. They will then send the infected SMS to all the phones in their contact list (some of which will be iPhones), which will then send the infected SMS to all of their contacts, etc. That probably covers 80% of all iPhone users.
Of course, the networks would likely be able to put a stop to this by filtering SMS messages containing the payload, but that would take some time and cooperation. If someone launched an iPhone worm, it would be likely that almost everyone was infected before AT&T and others had time to implement a patch.
If I were Apple, I'd be working ASAP to get AT&T to start working on the filter, because at this point, even publishing an iPhone update is not going to be enough.
Funny, no one paid much attention when this was posted four weeks ago. People never pay much attention to security until its about to bite them.
Ho hum, if you would like to avoid the SMS apocalypse you can hope that Apple releases a security update before the conference, or you can sign up for AT&T's Smart Limits for Wireless Parental Controls ($5/mo) and set your SMS quota to 0 (add your Mom to the whitelist first).
I'm not trying to be the dumbass comment but this better make its way to a celebrity phone somewhere. SOMETHING of real value has to come of this... obviously, other than a more secure SMS infrastructure.
