Security Flaw Found That Allows Control of iPhone 176
i_like_spam writes "The NYTimes is running a story about an iPhone flaw that has been found and documented by researchers from Independent Security Evaluators. Attackers were able to gain full control of the iPhone either through WiFi or by visiting a website with malicious code. The exploit will be demonstrated at BlackHat on Aug. 2nd at 4:45pm. Until then, 'details on the vulnerability, but not a step-by-step guide to hacking the phone, can be found at www.exploitingiphone.com, which the researchers said would be unveiled today.'"
Excellent! (Score:5, Funny)
Of course, the down side is that so can everyone else...
Re: (Score:2)
Find a weakness in something that's signed, and have that execute your code.
Makes me think about the dvd player in my kitchen.
Re: (Score:2, Informative)
Re:Excellent! (Score:5, Funny)
Re:Excellent! (Score:5, Funny)
Re:Excellent! (Score:5, Funny)
Re:Excellent! (Score:4, Funny)
http://donkeykong.mit.edu/wiki/images/0/09/Ipwned
Duke University (Score:2)
I cannot image the hole will last long or anyone will really care all that much. I've seen a number of exploits demonstrated to hack into bluetooth enabled phones and do malicious things like delete contact lists. This is only a hot story because of the phone's popularity.
Re: (Score:2, Funny)
Dan: Our network is flaking out then crashing. We need to find the problem before the Spring semester kicks in and we're really in trouble.
George: Hmm, the iPhone just came out the other day. I doubt that's a coincidence, it must be a faulty product.
Dan: Are you sure? I haven't heard about any of these issues on other campuses or companies. I think we should look into this further.
Duke WAS NOT Apple's fault (Score:5, Informative)
Yeah, I can see how you're confused, because all the news outlets reporting about how the iPhone destroyed Duke's network did not bother to report that it was all made-up crap.
Last week: [macworld.com]
This week: [duke.edu]
Maybe at least /. could bother to retract the story?
Nah, who cares, it's just your usualy weekly Apple bashing.
Re:Duke WAS NOT Apple's fault (Score:5, Informative)
http://hardware.slashdot.org/article.pl?sid=07/07
Re: (Score:3, Interesting)
Re: (Score:3, Funny)
Re: (Score:2)
Re: (Score:2, Insightful)
Mac zealots have long argued that windows sees way more viruses / malware and therefore macs are more superior.
The truth is that all devices and operating systems are hackable - it's motivation to do so that's required, and a la
Re:Excellent! (Score:4, Insightful)
Userbase isn't what makes a target "big." It's potential media exposure. The iPhone hype makes it a key target. The closed nature of the iPhone means lots of talented people are trying to break in. The iPhone, moreover, probably isn't as secure as a desktop computer. It's not designed to be open and from what I understand about this particular hack, it builds on previous "doors" which can easily be closed. It's not surprising that once you've gained access to a device, you'll be able to manipulate it (particularly when they're all configured with the same username and password).
There's plenty of media attention given to every half-assed attempt to break OS X. So far, nothing worth losing sleep over. You don't think that the media attention for OS X would be worth the payoff? Linux might have some protection because it's somewhat obscure and not mainstream--but while it might not show up on CNN, people here certainly would take note, and so would large corporations using Linux servers.
Rut roh... (Score:5, Funny)
Re: (Score:2)
Instead of looking for exploits just suggest that Steve Jobs and JK Rawlins should marry as this will be a meeting of alike souls. Extra bonus points could have been had for doing that on Saturday, 21st of July 2007 (provided that you had enough ammo to defend yourself after that).
Though, the magic day has passed, this is still a good treat if you want to observe how an otherwise normal looking person suddenly morphs into something out of a nightmare horror movie.
Re: (Score:3, Funny)
Re:Rut roh... (Score:5, Funny)
I can see the commercials now...
Mac and PC walk in from opposite sides of the screen. Mac is dressed as a ninja - custom-tailored silks, authentic-looking swords, the works. PC wears his typical clothes, but in a disheveled fashion reminiscent of Michael Douglas in "Falling Down", complete with briefcase in one hand and machine gun in the other. (Although it's painfully obvious that PC's "gun" is a cheesy plastic model acquired from the local toy store.)
The technical paper is the article (Score:5, Informative)
Re:The technical paper is the article (Score:5, Interesting)
Most interesting pieces of information from the article:
Under their suggestions:
I don't see how that'd help on a single-user computer., tho (another of their suggestions) chrooting all the running apps would be a step in the right direction. The researchers are politicians, too:
Translation: Running iTunes in a chroot jail makes the iPhone insecure, because my unicorn says anything done for the sake of AT&T is insecure.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
As someone who has spent a few decades programming computers in the C programming language (with a sprinkle of C++ and Objective-C), even I have to admit it's probably time to increasingly retire low level programming languages that are prone to these kinds of exploits (buffer overflows).
I wonder if there are "safer" languages than C with similar performance and memory usage characteristics.
Re:The technical paper is the article (Score:4, Insightful)
*sigh* I hate this argument.
Why not just disallow anyone not capable of not programming a buffer overflow from ever programming a device? It's not a language issue. I'm sure that unqualified folks will figure out how to cause all sorts of new vulnerabilities in "safe" languages. (Hint: there is no such thing as a "safe" language.)
I guess maybe I'm just in the "old school" camp that thinks that unqualified people shouldn't be allowed to do things. There's a reason why, for instance, amateur carpenters aren't allowed to construct public buildings.
Maybe we should actually require people to be licensed programmers...while that would weed out some of the problem, though, we all know that professional engineering licenses or whatever don't guarantee competence...
</rant>
Re:The technical paper is the article (Score:4, Insightful)
First off, it's not true. Even experienced programmers make mistakes, and I've had issues where the API I was writing to was incomplete, and my implementation and the other guys implementation were just different enough that, in the right circumstance, you could have a problem. That stuff happens. It's always going to happen.
Second, in my experience, no C programmer ever thinks that they make these mistakes, it's always crappy programmers from somewhere else. At some point, you have to own up to the fact that it's a problem of the language and that, as long as you use the language, you're going to have the problem.
Now, if we could find something that ran with the performance curve of well programmed and tuned C, but without C's baggage of errors, leaks, and overflows, this would be a no-brainer. Unfortunately, that language does not exist, and hardware hasn't gotten to a level yet to make language performance irrelevant for consumer applications.
So we have to put up with C's issues. But if a new language is developed, or if processors keep increasing, the day will come when C will join Fortran as one of those languages that really only academics need to know, and it's because of crap like this.
Re:The technical paper is the article (Score:4, Insightful)
Your post highlighted all the dangers of ad-hoc programming.
Personally, I've seen a lot of "experienced" C programmers but only met a few good C programmers. I don't blame the language, instead I blame the programmer who gives into temptation and think they could just quickly code an application on-the-fly without any planning. A decent analogy would be that while a large number of people are familiar with the english language, only a small percentage of them can write a decent novel.
I am a C/C++ programmer, and I believe that I am capable of making even the dumbest mistakes when coding (especially during an exceptionally long programming session). This is why I test! I make my unit tests with the intent of making sure my procedures error out correctly, as well as verifying that it works correctly. I put special effort in data objects that are prone to buffer allocation errors.
I also design the overall program ahead of time, define the interfaces between modules, and go over expected application behavior with the test engineer.
I go through this because (1) the only true way to make quality software is to put forth the effort to design, test, and maintain the code from the beginning, and (2) I never expect any language to handle errors correctly.
Number 2 is important, since even if a higher language does handle out-of-bounds conditions, does it handle it in a way that doesn't cause a problem somewhere else in the data chain?
For (off-the-top of my head) example, if I had a string buffer that automatically grew to 518 bytes to handle an erroneous data entry and it stored it in a database record that only held 512 bytes, does it truncate the data or does it posts a warning. Remember this error wasn't caught by the programmer, so are we to assume that the programmer would check for this error when it came time to place it in the database? Or what if the application simply threw an out-of-bounds exception? If it wasn't tested for this in production, then this means it could happen in the field. In my line of business, it must be caught in production.
The reason *I* use C and C++ is because I need the speed that comes from not having the language doing all my thinking for me. If *you* think C has issues then maybe *you* need to use another language more appropriate for your requirements and your skill set. BTW, my colleagues would have issues about your Fortran comment too!
I am not saying C/C++ is the best language for every situation. I am just saying that I use C/C++ because of performance and space requirements. I am also saying that no high level language is a good substitution for good programming practices.
The issues related to this story require even more effort in testing. We are not trying to catch simple runtime errors, we are trying to prevent someone who has the intent to break the security of a program. This falls outside of the realm of high level languages even with the issue that caused this particular "breach."
For (another off-the top of my head) example, even the best programs can fall victim to a compromised configuration file. So effort must be made to give an application the minimum amount of security privileges necessary to do its task *and* make sure that the configuration files are not modifiable without higher privileges.
Re: (Score:2)
In many situations, higher-level languages reduce the cost of "good programming practices" by reducing the number of specific concerns that need to be addressed in a program designed for a given task, compared to C or C++.
They are not intended as a substitute for good practice, nor has anyone that I have seen suggest them as a substitute.
Re:The technical paper is the article (Score:4, Insightful)
Now, not trying to be snarky or anything, honestly, but how often do you find that you run out of time on projects? Do you ever find that being so careful in your coding means that you get hounded for being late or behind schedule?
Re: (Score:2)
C is essentially a portable assembler. For C to function as it should, it needs to be able to do potentially bad things.
I've not seen one (usable) operating system not written in an "unsafe" language. Because eventually, we must get down there.
Re: (Score:2)
There are places where performance demands C, where the inevitable buffer overflow patch cycle is an acceptable trade off for speed. But there are a lot of other places where it's not the bes
Re: (Score:2)
For applications, there are many better choices than C. Python with wxWidgets and Java if you want reasonable cross compatibility, C# if you don't mind the monoculture associated with it, etc.
C needs to be able to access memory the way it does because sometimes memory just has to be memory. And I
Re: (Score:2)
Because then nobody would ever program a device.
Re: (Score:3)
Re: (Score:3, Informative)
would be easier to read as
"Why not just disallow anyone who has a history of programming buffer overflows from ever programming a device?"
although that changes the meaning slightly.
Re: (Score:3, Insightful)
Why not just disallow anyone not capable of not programming a buffer overflow from ever programming a device?
Because that's not realistic.
It's not a language issue. I'm sure that unqualified folks will figure out how to cause all sorts of new vulnerabilities in "safe" languages.
If you were to group bugs into two categories, "buffer overflow bugs" and "other bugs", the C programming language makes it possible for developers to code both kinds of bugs. If, by using a safer programming language, you can at least eliminate "buffer overflow bugs", why wouldn't you want to do that?
(Hint: there is no such thing as a "safe" language.)
(Hint: I never said there was such a thing as a "safe" language. I said "safer".)
I guess maybe I'm just in the "old school" camp that thinks that unqualified people shouldn't be allowed to do things. There's a reason why, for instance, amateur carpenters aren't allowed to construct public buildings.
Yeah, right. That'll happen, right after every little girl on the planet gets her very o
Re: (Score:2)
That said, I'd still pick Objective-C, and use NSString rather than C strings directly and live w
Re: (Score:2)
Most buffer overflow bugs are very easy to spot.
No, most buffer overflows not caused by inexperienced programmers are hard to spot. I found one in a piece of code I wrote that took quite a long time to track down. It expressed itself as a malloc warning on free... one execution out of a thousand or so. Turns out one malloc call was allocating a buffer that was one byte too small due to an off-by-one math error while doing some heavy-duty string manipulation. (No, it wasn't the NULL that I didn't ac
Re: (Score:3, Insightful)
Re: (Score:2)
Re: (Score:2)
Considering most languages these days (include C/C++; C++ much more so) already have facilities available to avoid most of these pit falls, I do not believe your comment has legs. Let's be honest here, the a huge chunk of these problems pop up because of complete indifference to the problems at hand. In these "safer" languages, different types of problems become more common, simp
Re: (Score:2)
Fixing the language requires one thing to change, fixing the people requires an ungodly amount of changes.
And the problem with the "the languages have these facilities already" argument is that those facilities are not available as the default and are rarely used even when they would be essentially transparent. Make it so one has to expend effort to turn the safety features off, r
Re: (Score:2)
To be clear, I believe languages like perl and python, so on and so on, are simply great! But I've seen some real crappy and buggy code which enables completely arbitrary execution of native perl, python, and even allowed SQL in
Re: (Score:2)
Re: (Score:2)
On a bicycle?
And why do you assume that an eliminated bug will necessarily be replaced by a different bug?
Because the lack of experience and general knowledge is often the cause of poor design which creates flaws by design or poor implementation. The later, if not creating a problem here will create a problem there.
The reality is, owning a screw driver does not make you a better mechanic. Owning an electric screw driver does not make you a better mechan
Re: (Score:2)
I dunno, the problem with analogies is that they are always wrong.
You're good mechanic may have diabetes causing his hands to shake. If he uses a manual screwdriver it will take him all day to finish a project. Give him the electric and he's done in seconds. Sounds to me like a good thing.
You're right that the tool is no replacement for a qualified professional but the tools can enable the person to do more in less time without having to worry about the small stuff they can move forward and start worryi
Re: (Score:2)
What has amazed me is the x86 only has one stack that's used by many
Re: (Score:2)
Take a look at D [digitalmars.com]. It's basically C++ with a first class String object and garbage collection, plus a few other nice things borrowed from various languages. It's performance characteristics seem to be on par with C and C++, but it has most of the nice bits from Java and C# as well.
Dear Author of Malicious Code (Score:5, Funny)
Signed,
Mac Zealot
My life for Aiur!....errr Steve Jobs!
Re: (Score:3, Funny)
Update Deployment (Score:4, Interesting)
Re:Update Deployment (Score:5, Informative)
Re: (Score:2)
Re: (Score:2)
I dare you explain why would OSX be more patchable than other phone operating system.
And if you start explaining it's because they based it off o
Re: (Score:2)
Reminds me of the Flash 2004 fiasco - see, they didn't have time to actually finish the documentation. So they thought: we'd just spend less time on making it super easy to UPDATE the help after the
Re: (Score:2)
Re: (Score:2)
When they do them.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
With the AT&T/Cingular plans, you have to take data and I believe it is unlimited. Still, as another poster suggests, I believe the updates will come via iTunes.
I wonder, however, if iPhone users will be prompted on the phone to seek the patch through their iTunes. My wife has an iPod which she hasn't sync'd since right after we bought it eight months ago. It would be nice if they had an app on the phone that tells you that you have a sec
Re: (Score:2)
no wonder they don't allow programming the thing (Score:3, Insightful)
Evidently (and, I suppose, not surprisingly), an OS X-based phone lacks these safeguard. I guess that's the real reason Apple has been refusing to permit third party phone apps on the iPhone, even though they don't cause problems on other phones: the iPhone software architecture just doesn't seem designed for it.
Re:no wonder they don't allow programming the thin (Score:4, Interesting)
This was a bit tricky but it worked fine on Nokia Series 60 phones an on Sony Ericsson P800 and P900.
I don't think that Symbian managed it in version 8 and 9 to build in a ground up security, because the SDK is huge with thousands of classes.
ok, let me restate that (Score:2)
OK, "from the ground up" is probably overstating it, but they are making an effort.
First, Symbian applications do need to get permission in order to get access to private data, phone services, and Internet services. If something equivalent were part of iPhone, it would be a lot less likely that a buffer overflow in Safari could be used to send SMSs.
Second, Java on Sym
Re:no wonder they don't allow programming the thin (Score:5, Funny)
1. The phone randomly locks up and/or turns off - this fools 3v1L hackers.
2. Won't connect to most Bluetooth devices - keeps hackers out. Very clever!
3. When syncing contacts, it mixes up all the fields so that an 3l33t hacker won't be able to make sense of them. You won't either, but at least you're safe.
4. Apparently has a built-in function to slow all operations to a C...R...A...W...L... - this prevents hackers from using high speed automated systems to hack your phone. Ingeneous!
Signed,
A proud owner of a Cingular Nokia (Swedish for moose dung) phone.
PS - Hack my phone. I dare you! Whoops . . . wait a minute. Let me reset it first.
Re: (Score:2)
You've never used an iphone have you? It takes this type of security to a new a level.
Re:no wonder they don't allow programming the thin (Score:2)
Damn, mod parent down. Mac OS X is a UNIX-based system, and has exactly those capabilities.
Re: (Score:2)
You don't know what you're talking about. Neither UNIX nor OS X have capabilities-based security by default. The term "capabilities-based UNIX security" refers to an optional security feature available on some versions of UNIX.
The Difference is Responsibility... (Score:5, Interesting)
The Apple community should not in any way, shape or form, harass this group like they harassed InfoSec Sellout. I.S.E. are the good guys and as a 15-year Apple veteran, I give my best to those who are out to help Apple keep security at its tightest on their products and services.
Re: (Score:2)
Unlike InfoSec Sellout (who is likely blowing smoke up his as*), Charles Miller and the rest of the Independent Security Evaluators team should be applauded for their work. They responsibly reported the vulnerability (and a potential fix) to Apple for investigation.
I totally agree. This is a clear-cut example of responsible investigation. They reported the bug to Apple and gave them a decent amount of lead time to work on the problem. It's no big surprise that Apple has already responded and the two groups are communicating to solve the issue.
People wonder why Apple doesn't respond to a group like InfoSec well the answer should be obvious: InfoSec is not in the investigation business to help solve problems, they are in it to cause problems. A lot of these groups
Re: (Score:2)
Re: (Score:2)
Explain the intrinsic unsafeness of Objective-C, as opposed to C or C++, and watch us laugh at you. Why doesn't Linus find all the vulnerabilities in the Linux kernel, after all, or the Apache guys in Apache, or the NT guys in NT kernel, or...
Explain the intrinsic unsafeness of the C dialects as opposed to Java, and watch us fall asleep while waiting for the Conway's Life game embedded on your home page to load up.
Explain the intrinsic unsafeness of the C dialects as opposed to C#, and watch us run screa
Re: (Score:2, Insightful)
Don't be silly! (Score:4, Insightful)
Java did not exist when NeXT chose Objective C as their development language. Objective C was arguably the technically most superior language for applications development. It was (is!) cleaner and more object-oriented than C++.
C-like languages may increasing have less merit for appsdev today, but they certainly still have their place. You and I know little about the iPhone. It may indeed be the case that running a JVM on it for all apps is a poor choice.
Re: (Score:2)
Re: (Score:2)
That's not even arguable. Like C and C++, Objective-C was a big step backwards compared to the state of the art in programming languages and application development languages in the 1980's. Java isn't a lot better, but at least it has runtime safety.
It was (is!) cleaner and more object-oriented than C++.
My toilet is cleaner and more object-oriented than C++.
You and I know little about the iPhone. It may indeed be
Re: (Score:2)
Now, for higher level applica
don't deflect from Apple's problem (Score:2)
All C-based languages are intrinsically unsafe, and that includes C and C++. If you use one of those languages and you don't have the development processes in place to make sure that you're producing bullet-proof applications (Apple evidently doesn't), people have a right to blame you and hold your feet to the fire over it.
as opposed to Java, and watch us fall asleep while waiting for the Conway's Life game embedded on your home page t
Re: (Score:3)
Neat - the interesting thing will be the response (Score:5, Interesting)
One functionality change that _should_ come out of this, though - I would turn off the default behavior of scanning for open networks and asking to join them. It wastes battery power, and the pop-ups for new networks are intrusive. In its place I'd put the AirPort icon in the display full-time (instead of just replacing the EDGE "E" when you are on a WiFi network) and allow quick access from there. I think, altogether, iPhone will be a pretty secure device after the initial flushing out of bugs, but this is a little different from traditional devices. iPhone has a classic desktop OS stripped down into a cellphone, whereas mainstream other devices (Palm, Windows CE, and Symbian) were designed more as cellphone systems (or PDA systems) and scaled up.
(not replacing my iPhone with a Razr anytime soon!)
It's not the OS, it's the application. (Score:2)
The first WinCE-based handhelds were pretty much "laptop replacements" with stripped down versions of Windows applications that r
this is backwards (Score:3, Insightful)
... (iPhone) is a little different from traditional devices. (It) has a classic desktop OS stripped down into a cellphone, whereas mainstream other devices (Palm, Windows CE, and Symbian) were designed more as cellphone systems ... and scaled up.
No offense, but this analysis seems quite backwards to me.
The main differentiating feature of the iPhone software is that it is a brand new GUI designed specifically for a portable communicator. It is specifically and closely tailored to the physical attributes of the device and the applications it contains, and merges the software functionality with the physical functionality into a seamless whole. It's very success is tied to this integration and the fact that it does *not* simulate a desktop environm
Re: (Score:2)
Kind of ugly though (Score:3, Informative)
iPhone owner is not surprised (Score:5, Informative)
Re: (Score:2)
An iPatch? (Score:5, Funny)
Good job there's no SDK, eh? (Score:4, Insightful)
Full Control? (Score:2)
Can anybody?
Re: (Score:3, Informative)
the iPhone , when unlocked, will only ever work with GSM networks (T-Mobile and AT&T). Any changes that move the phone to Verizon would require solder and hot-glue.
Bravo on the disclosure... (Score:2)
Apple is not losing any sleep because their handling of bugs isn't joy-making to either Maynor or LMH.
These guys are transparent and helping with the fix and should be rewarded for such.
Re: (Score:2)
A friend of mine has an iPhone and an email from the Debian security mailing list caused the mail app to crash. I also recall reading that most apps on the iPhone run as root. Might just be a nice buffer or stack overflow to be exploited.
Re:Stop waving that damn thing around (Score:5, Funny)
Re: (Score:2, Funny)
Re: (Score:2)
No, I'm sure that Apple wants to limit functionality everyone wants, because telling your customers what they want rather than listening to them and giving them what they want is a great business strategy.
I'm quite sure that if Apple could unlock it and make it 5x more useful to everyone, they would. It would only sell MORE units, not less.
AT&T have open phones now. (Score:2)
Not in the slightest. AT&T offer Blackberries and Treos [att.com], both having official third-party development tools and mature ecosystems of third-party software (much of it free and open source). Why is the iPhone an exception?
No matter any more, however. To restate my point, with the amount of effort being poured into iPhone hacking, it will only be a matter of time before people begin developing their own application
Childish. (Score:2)
What a pity it would be if nobody ever tried new, untried, and untested devices. At one point computers fell into this category.
Or maybe they thought features not available on other mobile devices would be compelling and useful. To name a few: powerful conference