iPhone SMS exploit to be revealed at Black Hat on 7/30

[Trippy]

How To Hijack Every iPhone In The World

Excerpt:

On Thursday, two researchers plan to reveal an unpatched iPhone bug that could virally infect phones via SMS.

If you receive a text message on your iPhone any time after Thursday afternoon containing only a single square character, Charlie Miller would suggest you turn the device off. Quickly.

That small cipher will likely be your only warning that someone has taken advantage of a bug that Miller and his fellow cybersecurity researcher Collin Mulliner plan to publicize Thursday at the Black Hat cybersecurity conference in Las Vegas. Using a flaw they've found in the iPhone's handling of text messages, the researchers say they'll demonstrate how to send a series of mostly invisible SMS bursts that can give a hacker complete power over any of the smart phone's functions. That includes dialing the phone, visiting Web sites, turning on the device's camera and microphone and, most importantly, sending more text messages to further propagate a mass-gadget hijacking.

"This is serious. The only thing you can do to prevent it is turn off your phone," Miller told Forbes. "Someone could pretty quickly take over every iPhone in the world with this."

[Samwise]

Excellent.  I hope something entertaining comes out of this.   

[Engels]

Ya, I heard about this on Security Now podcast last week. The dude unveiling the exploit told Apple they had till Thursday, and after that, he's presenting. Its not 'in the wild', as they say, and I wonder if this is one of those instances where one dude's presentation of an exploit is actually the catalyst for a security disaster.

That said, maybe this is the sorta thing Apple needs to gets its rear in gear re security. I believe they still have a security flaw in their proprietary Java engine still unpatched, going on months now.

[Oban]

I seriously doubt this will allow an iPhone to be remotely controlled without first installing some piece of software and/or having an already cracked phone.

If it is a buffer overflow, I doubt the phone would be able to accept additional sms messages and then open applications (hooray for no background processes).

[Salamok]

Gaining the ability to run remote commands is step 1 in installing whatever software you want to do whatever you want.  

edit: here comes the iPhone botnet.

[Samwise]

I think it's awesome that for years Apple has been able to tout itself as a "secure" platform largely because they didn't have enough market share for their machines to be worth attacking.  And now that they've finally got one of their machines in everyone's pocket...

[Quinton]

I seriously doubt this will allow an iPhone to be remotely controlled without first installing some piece of software and/or having an already cracked phone.

If it is a buffer overflow, I doubt the phone would be able to accept additional sms messages and then open applications (hooray for no background processes).

You would be amazed.  Stuff like this can and does happen.  We fixed a bug in the wifi driver for HTC Dream / T-Mobile G1 before 1.0 launch that could have allowed for a remote code execution exploit (in the kernel) via invalid beacon packets.

I don't know the details on this particular exploit, but if you've got a buffer overrun that allows you to inject and execute code, even if just a little bit of code, you potentially have a serious problem.

[Oban]

An SMS message could cause a buffer overflow, sure.

But, the iPhone would lock and no longer accept SMS messages.

Waiting with baited breath...

The article also mentions an SMS remote access exploit in Windows Mobile phones and a remote SMS exploit that will knock a Google Android phone off network for a period of time. 

Based on my experiences with HTC products I can believe that they would have issues, but the iPhone is locked down to an obscene degree.

[Samwise]

An SMS message could cause a buffer overflow, sure.

But, the iPhone would lock and no longer accept SMS messages.

The iPhone OS can't prevent a buffer overflow, but it can detect that one happened and immediately lock down the phone in response to it?  Buh?

Typically the point of a buffer overflow is to overwrite something in memory such that the system doesn't notice anything is wrong and blithely continues executing whatever it was about to execute (ideally the position in memory that you just overwrote with your own naughty bits).  If the system can catch that sort of thing, it just outright prevents it by not letting you write to memory that's not yours to write to.  And if that were the case there'd be no buffer overflow possibility here and no story.

[Righ]

I'm guessing that Oban is thinking that an application crash on the iPhone results in a system halt. A well crafted exploit will use the stack overflow to pass execution to its own code, so no application crash occurs. Sure, in order to create that exploit (even modifying some exploit for a new use) requires testing and hanging a few phones.

[Oban]

I am just not understanding how a malformed 160 character message is going to allow remote root access without touching some other application.

SMS reception is active, if the SMS application can no longer receive messages then it hangs.  (Which is quite common in CDMA phones since SMS is passed over a data channel as HTTP-type traffic as opposed to SMS messaging on GSM which is a signaling transmission.)

[Samwise]

Once a buffer overrun gets into instruction space, the application is no longer operating according to its normal logic.  You're effectively rewriting the application (at the machine language level) at that point and can get it to do whatever you want.  I'm not sure how the iPhone OS works or if it has a concept of different users with different privileges; if the SMS software runs on the iPhone as a "non-privileged" user and if the OS prevents applications from writing outside their own memory space, then there would be some limit to how much mischief it could get into.  If not, not.

[schild]

I am just not understanding how a malformed 160 character message is going to allow remote root access without touching some other application.

Not understanding how a hack works doesn't make it any less real. Are you saying before this post you were just talking out of your ass? Yes? Less of that.

My avatar is now laughing at all the iPhone users with his sweet block phone.

[Oban]

I'm not sure how the iPhone OS works or if it has a concept of different users with different privileges; if the SMS software runs on the iPhone as a "non-privileged" user and if the OS prevents applications from writing outside their own memory space, then there would be some limit to how much mischief it could get into. 

Yes, this is my understanding of how applications that interface with the gsm baseband work on the iPhone.

[Righ]

The overflow allows execution of arbitrary code. You send your code in an SMS message and precede it with the data required to exploit the vulnerability. What that does is pops a new address into the program counter of the processor. The processor then starts executing the code at that address. It doesn't matter what unprivileged user the code executes as, because the initial intention is to use the broken SMS program to send the virus out to all the people in the SMS address book, and we know that the code has the privs for that because it ran under the SMS application's ID.

However, since the authors are claiming full control, there must be a local privilege escalation that can be exploited from the SMS user.

[Jeff Kelly]

So for a little fame and street cred some hacker unveils a possibly dangerous security flaw at a hacker conference instead of working with the company that developed the product.

Additional points for "you have until x to fix it or I publish it but I wouldn't tell you what the flaw is".

Being a dick much?

[SurfD]

So for a little fame and street cred some hacker unveils a possibly dangerous security flaw at a hacker conference instead of working with the company that developed the product.

Additional points for "you have until x to fix it or I publish it but I wouldn't tell you what the flaw is".

Being a dick much?

Most of the "upstanding" (if i can use that word) "hackers" in the professional "hacker" community (ie, the types that routinely attend conventions like Black Hat) usually do send a full bug report explaining how the hack works to the company in question before issuing their ultimatum.

I imagine these people sent apple a full rundown on how it works and told them, fix it now, or we will force you to fix it through much wailing and gnashing of teeth.

[Jeff Kelly]

OK, I didn't know that.

How do they make sure however that said bug report gets to the right person in such huge companies as Apple or Microsoft?

[Trippy]

The article in the first post stated pretty clearly that the researchers contacted Apple about the exploit. However they only gave Apple an one month advance notice which to me is not enough time given the amount of testing that would need to be done even if the fix was relatively simple.

How do they make sure however that said bug report gets to the right person in such huge companies as Apple or Microsoft?

You send an email to product-security@apple.com which is listed near the top of their product security page. Or you could just call their PR department whose number is listed on their Contact Us page and I'm sure they could get you in touch with the proper person(s).

[Murgos]

Fixing the flaw will probably have trade-offs in all kinds of areas, people familiar with the issue pulled off other, possibly time sensitive, projects.  There may be a dozen ways to fix it but some will have other, unforeseen, consequences or maybe even foreseeable issues that also need fixing, and then testing and testing and testing while looking for other similar exploits.

Even if Apple jumped right on the problem with extensive resources one month may not be a reasonable amount of time to perform corrective action and publish a patch.  Heck, that particular bit of code may be something they bought as an IP block from some other company and Apple may not be legally allowed to muck with it and so they may have to jump through all kinds of hoops to get a fix in.

The habit of 'security-analysts' publishing flaws is one thing when the offending company knows about it and does nothing for years but doing it at short notice, particularly when it could affect so many people, is IMO, negligent.

[Cyrrex]

I hope my iphone gets taken over.  With any luck it will answer all my stupid email.  I haven't called my mom in a while either, maybe somebody will do that for me. 

[Jeff Kelly]

According to a german news report that flaw ist also "in other smartphones" notably Windows Mobile and Android (the only one already fixed).

[Samwise]

Fixing the flaw will probably have trade-offs in all kinds of areas, people familiar with the issue pulled off other, possibly time sensitive, projects.  There may be a dozen ways to fix it but some will have other, unforeseen, consequences or maybe even foreseeable issues that also need fixing, and then testing and testing and testing while looking for other similar exploits.

I may be betraying my ignorance of the intricate architecture of the iPhone here, but isn't fixing a buffer overflow a fairly trivial matter of checking or truncating your input before you copy it into a space that it won't fit into?  That's something that most people learn as part of learning any language that doesn't manage its memory at runtime; it's not rocket science.

[Signe]

I hope my iphone gets taken over.  With any luck it will answer all my stupid email.  I haven't called my mom in a while either, maybe somebody will do that for me. 

Call your mother!!! 

[Oban]

Something about malformed SMS messages sent in batches of 500 or more at a time that causes the iPhone to hang for a period of time.  Functionally, this is very similar to an issue with multi-part-SMS sent on CDMA networks and not having the http session from the SMSC closing properly.  They could be sending multi-part-SMS messages with http tagging on GSM and that might cause issues with the baseband hanging while waiting for the completion of the series.

Nothing about actually executing code on the iPhone as of yet. 

I am interested in how they could send 500 SMS messages at once though, unless they were running off of a private BTS (SDR hooked up to an SMSCG most likely) that the phone had associated with.

Normally that amount of message flow to a single end point trips a lot of alarms within the network, mostly because we assume the bastard is trying to use a cell phone to get around having to pay for a proper short code.

Eagerly awaiting more details...

[Cyrrex]

I hope my iphone gets taken over.  With any luck it will answer all my stupid email.  I haven't called my mom in a while either, maybe somebody will do that for me. 

Call your mother!!! 

OMG YOU SOUND JUST LIKE HER!!

[Trippy]

Fixing the flaw will probably have trade-offs in all kinds of areas, people familiar with the issue pulled off other, possibly time sensitive, projects.  There may be a dozen ways to fix it but some will have other, unforeseen, consequences or maybe even foreseeable issues that also need fixing, and then testing and testing and testing while looking for other similar exploits.

I may be betraying my ignorance of the intricate architecture of the iPhone here, but isn't fixing a buffer overflow a fairly trivial matter of checking or truncating your input before you copy it into a space that it won't fit into?  That's something that most people learn as part of learning any language that doesn't manage its memory at runtime; it's not rocket science.

That might fix the buffer overflow but that doesn't mean there aren't other things that would need to fixed to properly protect against this attack. E.g. it's possible that just fixing the buffer overflow still makes the phone susceptible to Denial of Service attacks by the onslaught of rapid fire SMS control messages.

Edit: deleted the Android reference

[Samwise]

That might fix the buffer overflow but that doesn't mean there aren't other things that would need to fixed to properly protect against this attack. E.g. it's possible that just fixing the buffer overflow still makes the phone susceptible to Denial of Service attacks by the onslaught of rapid fire SMS control messages which is effectively what a similar attack did to Android (it would disable cell service but you couldn't take control of the phone) before Google fixed it (I'm assuming this is the fix Quinton referred to above).

Agreed, that would still be a problem, but being able to DoS one phone is VERY different from being able to zombie every iPhone in the world.

[Trippy]

Yes but fixing those additional problems (if they exist) means the patch will take longer to release.

BTW: I deleted the Android reference cause I went back and reread Quinton's post and he didn't mention any DoS vulnerability so my example didn't make sense.

[Samwise]

See, if it were me, I'd fix the problem that has HUGE PR CLUSTERFUCK written all over it RIGHT NOW, or at least before the exploit was due to be published, and worry about the comparatively minor problems later.

[Sheepherder]

See, if it were me, I'd fix the problem that has HUGE PR CLUSTERFUCK written all over it RIGHT NOW, or at least before the exploit was due to be published, and worry about the comparatively minor problems later.

People are retarded.  If you tell them that Firefox is insecure, and point to it's extensive patch history as proof, they'll pat themselves on the back for being the real genius for not switching from IE8.  Horsefuckers like those that market IE8 absolutely love to point to their own inadequacies as proof of their superior coding method (because it doesn't get fixed as much).

To the rest of this but they need time to fix it properly shit: The blacks hats, in fact, do have a very visible bias and/or agenda.  They want every horsefucker out there to fix his shit immediately.  I don't see what exactly is objectionable about asking a horsefucker to enforce type security.  Likewise, I shouldn't have to live in perpetual fear of continent-spanning networks being assraped without lube by a Russian zombies because it isn't fucking patch day yet.

I shouldn't post after drinking, it brings out the inner Haemish-style raging manchild that he pulls off so eloquently.

[Jeff Kelly]

The problem is that those biased black hats never worked in a company of what you affectionately called "horsefuckers".

They are used to open source projects where they just check out the code, fix it, send the patch to the maintainer and be done with it.

This doesn't work in big companies even if they have a tendency to move fast. 4 Weeks is extremely short notice for a company that employs 15.000 people and where you have a whole release process that makes sure that not every "horsefucker" breaks your whole project just by checking in a "minor fix" that hasn't been tested and verified not to break other stuff. Oh and don't forget that the firmware has then to be deploxed to every device on every network worldwide.

So 4 weeks, big company holiday season. Extremely short notice. We aren't talking about your run of the mills open source project here.

[Engels]

Uhm were you being sarcastic? Because I hate to break it to you, but MS has been patching their systems over this remarkable thing called the internets for, what, nearly a decade?  MS even manages to push patches out of cycle for special zero day threats. Not that MS is the paragon of security, by any means, but I suspect that their exposed vulnerabilities are a product of marketshare rather than being inherently less secure than Apple.

What we're seeing here is in all likelihood the product of years of complacency on Apple's part. This isn't the first time they have been slow with critical security flaws.

Apple has known for six weeks (not the four you mention) and only yesterday have they publically mentioned they are 'working on it'.

[Righ]

These security researchers are imposing their own 'time-to-fix' on the industry, that's true. The timetable is also biased in favor of helping their academic goals. However, if the companies involved in producing vulnerable products had hired their own researchers and had discovered the flaws, they would be the ones setting the timetable. Instead they sold vulnerable products to consumers, cheaped out on their own security analysis and are now presumably upset because somebody else who did the work on their own dime won't just shut up for an indeterminate amount of time so that they can sell more vulnerable products.

I can't side with Apple et al. here. Hire some more security analysts yourselves instead of hoping that academics will find the flaws for you and then fail to publish so as to allow you to hold off until the next product cycle. More crappy business cost cutting I'm afraid.

[NiX]

I can't side with Apple et al. here. Hire some more security analysts yourselves instead of hoping that academics will find the flaws for you and then fail to publish so as to allow you to hold off until the next product cycle. More crappy business cost cutting I'm afraid.

This is interesting stuff for those of us not in the know. Are there any large documented cases of a company actually waiting for the next product life cycle to implement a solution to a large security flaw?