Security Firm Reveals iPhone Vulnerability

[BobZimmerman]

I don't have any more information than you do. A few points:

1. Use Google to query the string "iphone buffer overflow".
2. Maybe you don't understand what is happening in the video that was posted... they load a web-page that simultaneously crashes Safari and runs their code. Seems what's going on is pretty clear to me.
3. Another clue: the report says the vulnerability also exists in OS X Safari and Windows Safari. If this doesn't mean anything to you - you don't get it.
4. The full vulnerability will be revealed at Black Hat. By then Apple can patch Safari. That's why you can't see it now -- not because it doesn't exist.

Denial doesn't make systems any more secure. This could have happened on any other device just as easily. There is no need to get excited or defensive about it.

My issue with using Google to find details on this is that Google reflects public perception more than it reflects reality. The media was reporting it as a buffer overflow. The people who documented and claimed the vulnerability did not call it that. Nowhere in their actual materials did they call it any kind of overflow.

As for the video, you do realize how easy it is to rig demos like that, right? After the airport fiasco, my standard for disclosure is a lot higher. These people didn't even come close to giving the community enough information to verify the issue independently. Thus, I discounted the issue as marketing for the time being and decided to wait until they revealed what was actually going on at Blackhat tomorrow. I was mostly wanting to shoot down some of the stranger things I was seeing in this thread.

Yes, the report says that, but it doesn't necessarily mean anything. At this point, when a vulnerability in something that has been getting a lot of media attention is reported but not disclosed, it looks very much like a hoax. Again, the airport "vulnerability" springs immediately to mind.



Anyway, it would seem that I was wrong and this apparently can lead to ACE:

Safari
CVE-ID: CVE-2007-3944
Available for: iPhone v1.0
Impact: Viewing a maliciously crafted web page may lead to arbitrary code execution
Description: Heap buffer overflows exist in the Perl Compatible Regular Expressions (PCRE) library used by the JavaScript engine in Safari. By enticing a user to visit a maliciously crafted web page, an attacker may trigger the issues, which may lead to arbitrary code execution. This update addresses the issues by performing additional validation of JavaScript regular expressions. Credit to Charlie Miller and Jake Honoroff of Independent Security Evaluators for reporting these issues.

It's still not a 'remote code execution' flaw as is being widely reported, and I'm still wondering how they verified arbitrary code execution when the researchers couldn't possibly have had a working toolchain to compile that code when they discovered the issue.

I suppose we'll find out more tomorrow.

 

[trngmchn]

As for the video, you do realize how easy it is to rig demos like that, right? After the airport fiasco, my standard for disclosure is a lot higher. These people didn't even come close to giving the community enough information to verify the issue independently.

...

It's still not a 'remote code execution' flaw as is being widely reported, and I'm still wondering how they verified arbitrary code execution when the researchers couldn't possibly have had a working toolchain to compile that code when they discovered the issue.

Bob, I don't mean to pick on you, but you still have some misunderstandings. First of all, don't you think it would be strange for a reputable company to rig a demo like this? It wouldn't make sense. Second, if enough information was given to independently verify the issue then the exploit would have instantly gone wild. Now that the patch has been released, it is no longer an issue and we should see the details this week.

Now, the part that is really getting under my skin is this one issue that you just don't understand. It is a 'remote code execution' flaw. You don't need a toolchain or a compiler to run arbitrary code. You only need to know information about the processor architecture and how to write assembly code for that particular architecture. This is the case for any buffer overflow exploit, for just about any platform. I don't know what your background is and I know this may be hard to understand, but if you ever decide to write an buffer overflow exploit yourself, this fact will become immediately obvious.

 

[Fairly]

The media was reporting it as a buffer overflow. The people who documented and claimed the vulnerability did not call it that.

But that's what it was. Draw your own conclusions. To some of us it's pretty obvious.

As for the video, you do realize how easy it is to rig demos like that, right?

I agree. I never trusted those attention whores at the NSA and Johns Hopkins anyway. This proves everyone's suspicions were correct.

After the airport fiasco, my standard for disclosure is a lot higher.

I think you should make ISE aware of your new standards.

These people didn't even come close to giving the community enough information to verify the issue independently.

Of course not.

At this point, when a vulnerability in something that has been getting a lot of media attention is reported but not disclosed, it looks very much like a hoax.

No it does not. It instead looks like a fortnight's reprieve for the vendor to patch.

Again, the airport "vulnerability" springs immediately to mind.

For some people it does. And at the same time the names Lynn Fox, Jim Dalrymple, and David Chartier spring to mind too.

It's still not a 'remote code execution' flaw as is being widely reported

Who cares what they call it? You're missing the bigger picture. The regex library which was supposed to be updated a year ago was updated finally on Monday only because ISE forced Apple to.

What would have happened if black hats knew of this and were exploiting it?

How do you know they weren't?

 

[Fairly]

Now, the part that is really getting under my skin is this one issue that you just don't understand. It is a 'remote code execution' flaw. You don't need a toolchain or a compiler to run arbitrary code. You only need to know information about the processor architecture and how to write assembly code for that particular architecture. This is the case for any buffer overflow exploit, for just about any platform. I don't know what your background is and I know this may be hard to understand, but if you ever decide to write an buffer overflow exploit yourself, this fact will become immediately obvious.

Quite. After all, that's the whole point of it - you're making a remote app do something it didn't intend to do - something you want it to do. The whole point is you don't have to come into contact with the target and you can still squash it.

 

[Kawasaki]

Everything has a vulnerability if you try hard enough. I don't know why people expect perfection.

 

[Fairly]

Everything has a vulnerability if you try hard enough. I don't know why people expect perfection.

What a name. Kawasaki that is. Wouldn't be Guy Kawasaki by any chance?

Is your middle name "Troll" too?

 

[SC68Cal]

I don't know why people expect perfection.

It's not like Apple markets their products to people with that expectation.

"It just works," after all.