Read the pwn2own rules that were posted earlier, I did: The computers were connected via a crossover cable with the target computer exposed to the attacker via it's internet connection.
Now read about ARP poisoning and Man-in-the-middle attack again. You will figure it out.
What makes you think ARP poisoning or mitm has anything to do with Miller's exploits?
That's not a rhetorical question. I'm asking you to provide evidence that these were actually used in Miller's attacks. I found some evidence about how Miller performed his attacks, and neither mitm nor ARP poisoning appears to have been a factor at all.
You seem to think these are significant, but as I posted before, the crossover cable and attacker-as-gateway measures are taken at least as much to protect the exploit from being observed and logged, and to present the maximum attack surface for the contest, as for any other reason. You seem to think they're necessary for the exploit to work. My position has consistently been that they're not.
The evidence I found on the details of Miller's successful attacks can be found by googling the following keywords:
site:zerodayinitiative.com charlie miller
site:support.apple.com charlie miller
One attack used JavaScript regular expressions, and the other used an embedded Compact Font Format (CFF) font. Look at the reporting dates and the participation of ZDI. These look like Miller's winning exploits to me.
Conspicuous by their absence are mitm and ARP poisoning attacks.
How can the opening be exploited by the attacker if the connection is secured by a router or server at some point in between the attacker and the target, as in over WAN?
You can create the hole but you can't get in unless on insecure LAN. If I am wrong about this I would like to know.
You're wrong.
Your view of what constitutes a compromise is far too narrow. Real bad guys don't play by those rules.
The maliciously crafted data contains the code (or vectors to code) that will be executed by the client. If that code performs, say, an HTTP GET to an attacker's URL, with the URL-encoded data that was compromised as a query string, then that compromised data has now been transferred to the attacker's remote URL. If the transfer occurs over HTTPS, then the compromised data is not visible to any other observers, such as another machine on the LAN using 'tcpdump' in promiscuous mode, or say Interarchy in traffic-watching mode. All the observer sees is an HTTPS transfer to an IP address, if they see anything at all.
It could also make a separate GET to obtain more malicious code, so the maliciously crafted data contains the minimum simply to trigger the exploit.
Furthermore, the attacker's remote URL need not be some clearly nefarious black-listed server that no respectable person would visit. It could be any server, such as Amazon S3, where someone can setup an account that can receive GET requests and log the request's content. It could even be a hacked account on such a server. Or multiple hacked accounts on servers scattered around the world. Or it could be any public but unhacked server that accepts arbitrary user-posted data, such as pastebin.com, and so on. Frankly, the possibilities are almost unlimited.
The way you seem to be thinking about it is that the attack has to first establish itself as a separately running process on the target machine, and it then listens on a port for incoming commands before it can perform any nefarious deeds. That is one way to compromise machines or connect them in a botnet, but it's certainly not the only way to compromise user data.
Is it possible if connected directly to the internet without a router? This has implications for all OSes if so.
Yes. And yes.
Remember we are not talking about malware here.
Huh?
Of course we're talking about malware. Remotely originated malware, that arrives as apparently innocuous data, but contains malicious executable code.
Your view of what constitutes malware seems to be too narrow, almost bordering on naive.
How does this bug with handling SMS messages have anything to do with MAC OSX?
It doesn't. It merely refutes your statement that "... none of the OSes were hacked until the user of the target computer was instructed by the attacker where to go to get hacked".
iPhone OS was one of the OSes.
It was hacked without the user being instructed where to go.
Therefore your statement was wrong.
You made a statement. I responded to it with evidence it was wrong. That's how debate works.
What type of network connection was the iphone using?
It was compromised by receipt of an SMS message. I think that narrows it down sufficiently.
