
The Fully Remote Attack Surface of the iPhone - lelf
https://googleprojectzero.blogspot.com/2019/08/the-fully-remote-attack-surface-of.html
======
lawnchair_larry
One thing I like about this post is how it enumerates all of the dead ends
that involved a lot of investment but produced no fruit. This is what is
difficult about exploiting hard targets. What the general public doesn’t see
is the massive amounts of “wasted” time involved in bug hunting. Instead, they
see the headline about how some wunderkind exploited X in a matter of seconds
or minutes, conveniently omitting the part where that person spent the last
year staring at code, writing tools, fuzzers, test harnesses, and finding
nothing at all - not knowing if they would ever find anything, or if there is
even a bug to be found.

~~~
jchw
There is something to be said though, and that is that there is always
_something_ to be found _somewhere_. Lacking toolchains that can fully
eliminate bugs, there will always be bugs. And even if there were legitimately
no bugs, that doesn’t mean there won’t be bugs introduced in future releases,
or bugs even outside the software itself.

The low hanging fruit has definitely been thoroughly picked these days, at
least in software like iOS. But yet with pretty much near certainty, exploits
find a way.

Perhaps even more fascinating, is that closing off one class of exploits
always seems be followed by new kinds of exploits, like clockwork. You’d think
eventually this would stop happening, but so far it hasn’t. CPU side channel
attacks may not be completely new, but they’ve emerged as one of the new big
targets as of late.

I really know little about security personally and obviously the amount of
work that goes into serious security research should never be underestimated
but I’m impressed at the inevitability of security bugs. Very few large
programs escape a regular cycle of bugs. Maybe OpenBSD is the best example of
Pretty Secure software.

~~~
wahern
> The low hanging fruit has definitely been thoroughly picked these days

The problem is that vendors aren't in the business of perfecting existing
software. They're in the business of pushing out big, bold, feature-rich
changes and additions.

There's always new low hanging fruit.

~~~
panic
The vulnerabilities found in the article support your argument: SMS and MMS,
which barely ever change or get new features, were much more secure than
iMessage, which constantly gets new features and architectural changes.

~~~
wahern
There was a Microsoft Research paper several years ago which looked at the
relationship of exploits to age of code in BSD kernels. The number of exploits
in older code diminished over time, but that was often offset by the higher
prevalence of exploits in newer code. That much is intuitive, but it's good
that there's some well researched empirical evidence showing that that's the
case.

We can hypothesize that better languages and better mitigations (e.g. ASLR)
can improve the situation across the board, and I don't doubt that that's the
case, but I haven't yet seen the evidence. (Maybe I missed it?) It's probably
too early as it's difficult to make apples-to-apples comparisons across those
aspects.

------
jorangreef
> some email providers also filter incoming messages and remove malformed MIME
> components that are needed to reach a vulnerability.

I wrote @ronomon/mime [1] for this purpose, to protect downstream user email
clients from MIME bombs [2], invalid charsets which can crash Apple Mail,
multiple From headers which can exploit Gmail [3], attachment directory
traversals, malicious continuation indices, truncated MIME messages, stack
overflows etc.

[1] [https://github.com/ronomon/mime](https://github.com/ronomon/mime)

[2] [https://snyk.io/blog/how-to-crash-an-email-server-with-a-
sin...](https://snyk.io/blog/how-to-crash-an-email-server-with-a-single-
email/)

[3] [https://blog.cotten.io/ghost-emails-hacking-gmails-ux-to-
hid...](https://blog.cotten.io/ghost-emails-hacking-gmails-ux-to-hide-the-
sender-46ef66a61eff)

------
mrgalaxy
> VVM works by fetching voicemail messages from an IMAP server maintained by
> the device’s carrier. The server URL and credentials for this server are
> provided to the device by the carrier over SMS.

Visual voicemail is just IMAP and SMS? Wow, for some reason I assumed there
would be some distinct protocol for that. It's pretty interesting that it's
implemented using the existing software the phone already runs on.

~~~
josho
And frustrating to learn that an open protocol with free implementations is
locked behind a carrier that often requires significant fees for this feature.

~~~
todd3834
How much does visual voicemail cost? I've never really noticed any significant
fees on my bill related to it.

~~~
Falling3
$2.99 for me. Not a huge cost, but certainly frustrating considering the non-
existent burden to the provider.

~~~
rizwank
Who charges for VVM?

~~~
sysbin
Bell.ca charges for it.

~~~
radicaldreamer
Man.. Canadian telecoms really suck

~~~
cdmckay
Nickel and dime’ing is easier than innovating.

------
usmannk
How do they actually run the iOS OS code involved in this debugging?
Jailbroken iPhones? iOS virtualization ala Corellium
([https://corellium.com](https://corellium.com))?

~~~
Hitton
Probably so called "Dev-fused iPhones".

~~~
saagarjha
The code presented in the article seems like it would run on any jailbroken
device.

------
saagarjha
> We looked at this extension in great detail, looking for a way to spawn a
> WebKit instance on the receiving device, but did not find any. The WebKit
> processing always appears to be done by the sender.

This is done for privacy reasons, AFAIK: it prevents “read receipt” links like
you might find in emails. It does however allow for the sender to attach a
misleading thumbnail, though.

------
zabuni
What's really cool is that they released all the code they used to create the
attacks.

[https://github.com/googleprojectzero/iOS-messaging-
tools](https://github.com/googleprojectzero/iOS-messaging-tools)

Just went to the talk. TL;DR: iMessage uses old serialization libraries, they
are terrible.

~~~
jhatax
The final few paragraphs touch upon how expansive the attack surface can be
due to this serialization code. So, yes the libraries are terrible.

Asking the HN audience: Is there a set of design principles that the iMessage
team can follow to make these more resilient to such attacks while retaining
their usability? As a non-Apple employee whose globally dispersed family
relies on iMessage to stay in touch, I have a vested interest in the security
of my family’s iPhones. I know it’s rare for Apple employees to comment, but
it would be great if someone from Apple can comment on whether these libraries
are being re-architected in some way. This will cut through any FUD that
arises from this disclosure / discussion.

------
fulafel
If this aims to enumerate all the vectors, it seems to be missing the lower
level radio & networking attack surface - eg the WLAN one that was a high-
profile Project Zero finding some time ago. And common networking things like
DHCP client, mDNS, VPN protocols, etc. Probably there are WLAN driver style
vulnerabilities in the cellular side too.

~~~
bowmessage
I was thinking phone-over-WiFi would be interesting to explore as well.

------
snazz
How many people were working on this project for how long? Also, is APNs
something they took a look at? No mention of it in the article, which is
surprising. Maybe they figured that it would be impossible to inject something
into a push notification.

~~~
cjbprime
The blog post describes who did the work, right? Looks like one person for
half of it, joined by another person for the second half.

------
ehsankia
I'm curious, does Apple pay the normal bug bounty to Google for finding these
exploits?

~~~
rootusrootus
I asked this question the last time this came up and the answer I got was
"Project Zero does not accept bounties. They generally ask for the money to be
donated."

~~~
ehsankia
That makes much more sense, it's not like Google _needs_ the money, so going
to charity is much better. Now the follow up question is, does Apple do that?

------
canacrypto
Fine work here.

------
godelmachine
Is this the first successful remote exploit of the iPhone?

If I am not wrong, Android has been exploited multitude of times.

~~~
vageli
> Is this the first successful remote exploit of the iPhone?

No? [https://www.cvedetails.com/vulnerability-
list/vendor_id-49/p...](https://www.cvedetails.com/vulnerability-
list/vendor_id-49/product_id-15556/Apple-Iphone-Os.html)

------
mettamage
So what's the motivation of Google? Are they are charity now?

I phrase it a bit unnuanced, but it does leave me a bit puzzled. I suppose
companies can be nice and not nice at the same time, but I'd rather look at
the level of incentives first before looking at the level of being nice.

~~~
rkangel
Google has said in the past "we make our money from usage of the internet, and
so anything that increases internet usage helps us".

That was their stated motivation behind things like Chrome - increase the
speed and utility of webapps so that more things could be online. It works in
this case because they are improving security and therefore user trust in
online services in general..

The cynic in me is sure that that's not the only reason, but it's part of the
picture.

~~~
kps
Project Zero is a Chrome project, so I assume the intent is to find
vulnerabilities elsewhere in the system that could end up tied to Chrome.

