A pair of European researchers used the spotlight of the CanSecWest Pwn2Own hacking contest to break into a fully patched iPhone and hijack the entire SMS database, including text messages that had already been deleted.
Using an exploit against a previously unknown vulnerability, the duo -- Vincenzo Iozzo and Ralf Philipp Weinmann -- lured the target iPhone to a rigged Web site and exfiltrated the SMS database in about 20 seconds.
The exploit crashed the iPhone's browser session but Weinmann said that, with some additional effort, he could have a successful attack with the browser running.
"Basically, every page that the user visits on our [rigged] site will grab the SMS database and upload it to a server we control," Weinmann explained.
"This exploit doesn't get out of the iPhone sandbox," Flake explained, noting that an attacker can do enough damage without escaping from the sandbox. [...] In addition to hijacking the SMS database, Weinmann said the winning Pwn2Own exploit could have exfiltrated the phone contact list, the email database, photographs and iTunes music files. In the iPhone sandbox, Weinmann said there's a non-root user called `mobile' with certain user privileges. "With this exploit, I can do anything that `mobile' can do."
Visit web site on iPhone, expose entire SMS database!
iPhone hacked, SMS database hijacked
Tags: computers, phones, security
Current Music: Kenickie -- Spies ♬
6 Responses:
Of course. Your personal data aren't somebody else's copyrighted materials that you've paid for, so why partition access to them?
The mobile user is responsible for reading to and writing to the data. Exactly how would *you* partition them?
By having, say, a separate user called omginterwebs for handling browser use? I can't see a plausible argument for the browser to have access to the SMS database, other than that it's less work to have a single userid handle all the internal data without regard for whether that's appropriate or not.
(for userid, substitute role, sandbox, etc. as you feel the need. The principle remains the same)
Android uses a separate UID per process. OTOH, perhaps the reason nobody attacked it in this last round is due to less marketshare, so I suspect Apple isn't so sorry they spent more time on the user-visible aspects of the phone.
Android's use of different UIDs doesn't solve this problem at all, since they intentionally provide access to all of this personal data via Java APIs!
An Android app doesn't need to use haxxors to make off with all your data.
What you wrote is correct, but the thread was about browser exploits. Unless you mean the browser app has access granted to all data on the phone, which would sound like a mistake.