Stories
Slash Boxes
Comments
Search

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Security Flaw Found That Allows Control of iPhone

Posted by Zonk on Mon Jul 23, 2007 07:05 AM
from the there's-always-a-catch dept.
Security Businesses Communications Handhelds Apple Hardware
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.'"
+ -
story
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Security Flaw Found That Allows Control of iPhone 25 Comments More /

 Full
 Abbreviated
 Hidden
More
Loading... please wait.

  • Excellent! (Score:5, Funny)

    by TheRaven64 (641858) on Monday July 23 2007, @07:10AM (#19954003) Homepage Journal
    Now users of the iPhone can control their own device!

    Of course, the down side is that so can everyone else...

  • Rut roh... (Score:5, Funny)

    by EveryNickIsTaken (1054794) on Monday July 23 2007, @07:18AM (#19954037)
    Sounds like someone's going to be getting Apple Fanboy death threats tonight....

    • Re:Rut roh... (Score:5, Funny)

      by Odin's Raven (145278) on Monday July 23 2007, @09:58AM (#19955401)

      Sounds like someone's going to be getting Apple Fanboy death threats tonight....

      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.)

      • Mac: Hi, I'm a Mac Fanboy death threat.
      • PC: And I'm a PC Fanboy death threat.
      • Mac: The other day someone claimed an Apple product was less than perfect.
      • PC: Every day people say I'm no good. Every...damn...day.
      • Mac: I hear ya, PC. In my case, I've assembled a multimedia production based around video clips taken while discretely stalking the person responsible, as text seamlessly scrolls past detailing the inherent superiority of the product in question and Mozart's "Dies Irae" from his "Requiem in D minor" plays in the background. (Pulls out iPhone and shows to PC - we catch glimpses of the movie and hear a snippet of music.)
      • PC: I have a powerpoint slide I send the offending party. (Opens briefcase and pulls out a tattered piece of paper, hands to Mac).
      • Mac: (Reading paper) Hmmmm, "U r a lozer and yu is teh suckz. Im gona hurtz u 4 ur makking fun of me. Micrsfort rulez!" Yes, that should certainly make an impression. Nice use of the WingDings font for the dagger.
      • PC: Thank you. Some people think I'm limited to boring text, but I do have access to some pretty snazzy graphics.
      • Mac: Yes, I've never seen anything quite like it. Oh well, I'm off to infiltrate the home of the person who offended me, silently scaling the outside wall, entering through an open skylight, and performing a triple-backflip as I drop to the floor, where I'll leave my threat nestled in a bouquet of lotus flowers.
      • PC: (Rolls eyes, clearly unimpressed.) Whatever. I'm going to catch the midtown bus, and nail my threat to the person's front door. And if they give me any lip, I've got this!
      • (PC brandishes toy gun, pulls trigger. Gun plays a few seconds of 80s-era laser sounds, which trail off as the batteries die.)
      • PC: Darn, why does this always happen? Now I've got to get a new weapon.
      • Mac: Do you want to call a few places, see what's in stock? (Offers iPhone to PC)
      • PC: Thanks, I ... (starts to reach for iPhone, changes mind.) Ummm, no, actually I'm good. Everything's just fine. Okay, gotta go.
      • (PC shuffles dejectedly offscreen. Mac watches PC leave, then does a backflip out of frame.)

  • The technical paper is the article (Score:5, Informative)

    by nmoog (701216) on Monday July 23 2007, @07:26AM (#19954077) Homepage Journal
    Have a read of the technical paper [securityevaluators.com] from the article - Quite interesting. They used fuzzing to find a heap overflow vulnerability. They go on to talk of "Blackbox Exploitation", which I later realise has nothing to do with the cinematic genre.

    • Re:The technical paper is the article (Score:5, Interesting)

      by iluvcapra (782887) on Monday July 23 2007, @08:05AM (#19954291) Homepage

      Most interesting pieces of information from the article:

      Additionally, no address randomization was used in by the operating system.

      the filesystem accessible to iTunes is chroot'ed such that only a small set of the filesystem is visible over this [USB] connection.

      it is possible to modify the iPhone in such a way that the applications will dump core files when they crash. This is accomplished by adding the file /etc/lauchd.conf containing the line limit core unlimited to the iPhone using iPhoneInterface. Core files can be retrieved off the iPhone from the /cores directory, again using iPhoneInterface.

      Under their suggestions:

      Install applications such that they run as an unprivileged user. This would result in a successful attacker only gaining the rights of this unprivileged user.

      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:

      This limited access to the filesystem doesn't particu- larly serve a security role from the perspec- tive of a remote attacker. Instead, this serves as an example of design intended to protect the exclusivity of the iPhone to AT&T. If more thought had gone into protecting the applica- tions from remote attack and less on prevent- ing the unlocking of the device, the overall security of the device might have improved.

      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:The technical paper is the article (Score:4, Insightful)

        by ThosLives (686517) on Monday July 23 2007, @08:54AM (#19954655) Journal
        <rant>

        *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>

        • You can't just say, "Only super-leet programmers should be allowed to program C, because we never make mistakes."

          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)

            by Bill_the_Engineer (772575) on Monday July 23 2007, @10:38AM (#19955903)

            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.

  • As a loyal Mac user and iPhone user I have to kill you.

    Signed,
    Mac Zealot

    My life for Aiur!....errr Steve Jobs!

  • Update Deployment (Score:4, Interesting)

    by da_matta (854422) on Monday July 23 2007, @07:53AM (#19954207)
    It's interesting to see what the response to this will be and how long it will take to for Apple to to release and deploy a patch. Mobile phones don't typically the "fast background patching"-systems like PC's (mobile data typically costs so you can't keep checking for updates). And everyone remembers from "pre sp2"-XP what it means if it's up to the user to check and deploy patches (e.g. iTunes).

    • Re:Update Deployment (Score:5, Informative)

      by jrumney (197329) on Monday July 23 2007, @07:57AM (#19954231) Homepage
      iPhone patches will be delivered automatically through iTunes, the same way iPod ones are. So while you won't get them OTA, it is still better than most cellphones which require you to go out and find patch installers, and in some cases these can only be obtained from official servicing agents, not over the web.

  • The Difference is Responsibility... (Score:5, Interesting)

    by iMouse (963104) on Monday July 23 2007, @07:57AM (#19954227)
    Apple iPhone users should be content with the finding of an exploit by responsible security researchers. 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.

    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.

          • Don't be silly! (Score:4, Insightful)

            by hotsauce (514237) on Monday July 23 2007, @10:22AM (#19955743)

            Apple's problem is that it's inherited a lot of bad legacy technologies from NeXT.

            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.

  • Neat - the interesting thing will be the response (Score:5, Interesting)

    by jht (5006) on Monday July 23 2007, @08:15AM (#19954387) Homepage Journal
    Now let's see how long until the first iPhone patch comes out, and if any of the other glitches will be fixed at the same time or if it's strictly for security. Obviously Apple's already been working on iPhone patch #1 and is probably just about ready to push it out after a month.

    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!)

  • iPhone owner is not surprised (Score:5, Informative)

    by goodmanj (234846) on Monday July 23 2007, @10:21AM (#19955729)
    From TFA:

    [Fuzzing] involves sending malformed data to the device in an effort to cause a fault and make it crash. The vulnerability we discovered and exploited was found in MobileSafari using fuzzing.
    Since MobileSafari crashes every ten minutes or so for me with *well*-formed data, I'm not surprised to hear that this is possible. Apple *seriously* needs to push out a Safari bugfix asap, not just for security, but for usability.

  • An iPatch? (Score:5, Funny)

    by Anonymous Coward on Monday July 23 2007, @10:33AM (#19955851)
    If Apple releases an iPatch, does that mean they support piracy? Arrrrrr, avast ye LAN-lubbers!

    • Re:no wonder they don't allow programming the thin (Score:4, Interesting)

      by brilwing (659717) on Monday July 23 2007, @09:10AM (#19954791)
      I don't know the newer Symbian versions 8 and 9, but till version 7 there was no security in Symbian at all. Every program could do everything. I have programmed an installation program that opened a GPRS connection, downloaded a SIS file and installed it on the Symbian phone without user interaction!!!
      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.
    • Here are some more examples of Symbian security (apparently their first priority):

      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.

All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 Geeknet, Inc.