How To Hijack 'Every iPhone In The World'
forbes.com
forbes.com
those new android phones are coming out later this year, right?
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.
"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."
http://tech.yahoo.com/news/pcworld/20090702/tc_pcworld/apple...
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.
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.
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.
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.
... then you probably shouldn't release it.
(Also: Buffer Overflow? Hello? Did someone develop this ten years ago?)
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.
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.
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 ...).
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.
You'd have to be able to send a text message to every iPhone in the world in order to hijack all of them.
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.
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).
Once again, I am proven wrong.