
Remote iPhone exploitation part 2: a remote ASLR bypass - weinzierl
https://googleprojectzero.blogspot.com/2020/01/remote-iphone-exploitation-part-2.html
======
londons_explore
This exploit, like many before it, make use of NSKeyedUnarchiver.

It's a class which allows arbitrary types to be serialized on the wire.

I think it's time that Apple had a new policy that no NSKeyedUnarchiver will
ever go from one iPhone to another. They could do that by having a random 64
bit number in the header, and if the header doesn't match the local device,
refuse to unarchive.

Then all software that breaks, find new ways to encode the specific data they
need to send over the wire. Specifically, require they send a _specific_
serialized class structure (ie. something with a schema), rather than
something general purpose.

~~~
izacus
Using NSKeyedUnarchiver (and other language serializers) on the wire is also a
great way to make sure your product is going to be extremely hard to port to
other platforms. Even the plist version is not easy to handle outside Apple
world.

I've consulted many companies which found out that they need to expand beyond
Apple horizons, just to find out that their whole infrastructure is based on
Apple's binary formats which aren't well documented and are not easily (and
reliably) readable on other platforms.

Pragmatic move in these cases is to use formats that aren't platform dependent
- things like JSONs, Cap'n Proto, msgpack and others.

~~~
saagarjha
> your product is going to be extremely hard to port to other platforms

I'm sure this isn't a particularly troubling issue for Apple.

~~~
londons_explore
Im sure they'd like the _ability_ to port a service like iMessage to Android,
just to give them options incase a big competitor starts eating their user
base with cross platform support.

~~~
saagarjha
Apple could just build their frameworks for other platforms–they've done it
before.

------
blakesterz
It's always interesting to read about these things. It's amazing to me how
hard it is to find a bug like this.

Also interesting, zerodium would pay up to $2million for something like this,
and even more now on Android.

~~~
alpb
What's the business model of zerodium? Do they sell them on black market
somehow? Why is it able to pay $2M if they weren't going to be able to extort
more bounty from Apple (which at that point the security researcher herself
can go to Apple, as well?)

~~~
tptacek
Commercial vulnerability brokers don't pay out up front; they pay in monthly
tranches, and stop paying when the vulnerability stops working. It's not an
apples-apples comparison with bounty payouts.

~~~
wyxuan
What's the incentive to go to cellebrite rather than Apple? Cellebrite offers
more but Apple does lump sum, from what I can tell.

------
blinkingled
CCC video that explains this pretty well -

[https://media.ccc.de/v/36c3-10497-messenger_hacking_remotely...](https://media.ccc.de/v/36c3-10497-messenger_hacking_remotely_compromising_an_iphone_through_imessage)

------
Uptrenda
Man, security research is seriously elite. It's like a mixture of arcane
magic, invention, and treasure hunting. I wonder how much time it takes to
find vulns like this.

~~~
roddux
Months of dedicated research, utilising a wealth of knowledge that comes from
spending a not-insignificant portion of your career researching such bugs.

------
musicale
Google is so good at finding fatal iPhone security bugs, maybe Apple should
pay them. ;-)

~~~
Scarbutt
Obviously a business decision, it is in Google's to interest to protect their
services and official apps in all the platforms they support.

~~~
egdod
... and publicize vulnerabilities in their main competitor.

~~~
tylerl
Right, because they should instead publicize all their discoveries _except_
for the Apple ones. Because obviously.

~~~
egdod
That’s not what I said. There’s an incentive for them _to find_ Apple
vulnerabilities.

------
Animats
This is why I consider address space randomization to be a cosmetic fix that
doesn't solve the real problem - a memory safety violation - but gives an
excuse for not fixing the real problem. It just increases the cost of the
attack development beyond script-kiddie level. Most of today's attackers seem
to be competent and well-funded, either by nation-states, organized crime, or
the advertising industry.

~~~
_wldu
I agree. This is why rust and go don't need it. Address space randomization is
an attempt by the OS to workaround language problems (specifically C). Nothing
against C, I love it, but people really need to move away from it where
possible.

~~~
pjmlp
Plenty of languages don't need it, even some older than C.

This all comes down to C designers ignoring the security best practices of
other systems programming languages, and UNIX clones having mainstream
adoption.

Morris worm (1988) wouldn't have been possible in regular Modula-2 (1978)
code, nor Ada (1983), Mesa (1976), ESPOL/NEWP (1961), PL/I (1964), PL/S
(1974), BLISS (1970), just citing a couple of them.

Yet C17 still doesn't provide language features to prevent another Morris
worm, and the security Annex was made optional instead.

~~~
roddux
>ignoring the security best practices of other systems programming languages

Can you please expand on this point?

~~~
pjmlp
Bounds checking, explicit unsafe blocks, proper strings, explicit type
conversions, proper enumerations, checked arithmetic.

For example, ESPOL/NEWP was the first systems programming language with
explicit unsafe blocks, 8 years before C came into the world.

So hardware that was much weaker than PDP-11, and yet capable of supporting
such security features.

Burroughs B5000 OS is still being developed, nowadays known as Unisys
ClearPath MCP, and its top selling feature is being a mainframe system for
customers whose security is the top priority.

~~~
saagarjha
> Burroughs B5000 OS is still being developed, nowadays known as Unisys
> ClearPath MCP, and its top selling feature is being a mainframe system for
> customers whose security is the top priority.

What's special about it?

~~~
pjmlp
Implemented in a systems programming language has everything security related
that C lacks.

> Bounds checking, explicit unsafe blocks, proper strings, explicit type
> conversions, proper enumerations, checked arithmetic.

Plus a capabilities based security access, and unsafe blocks taint binaries,
requiring admin permission to be executed.

~~~
saagarjha
Are these OS or hardware features?

~~~
pjmlp
Language and OS features.

Recent hardware versions use Xeons.

Again, just features missing from C, and available in other languages.

Another notable feature, it did not make use of any Assembly, in 1961, because
all CPU features are exposed as compiler intrinsics.

------
saagarjha
Part 1: [https://googleprojectzero.blogspot.com/2020/01/remote-
iphone...](https://googleprojectzero.blogspot.com/2020/01/remote-iphone-
exploitation-part-1.html)

------
greenie_beans
so...as a dumb consumer, how do i protect myself from this?

~~~
ehsankia
Project Zero usually releases the details 90 days after they've found the
exploit, giving hopefully ample time for Apple to patch the bug. So assuming
they have, simply being on the latest version means you are safe.

~~~
bigiain
That's also assuming Project Zero found this first...

~~~
ehsankia
I guess it depends if the question was a more general "how do I project myself
from zero day" or "how do I protect myself from this specific zero day". For
the latter, yes someone could've been exploiting it in the past, but right
now, it's been patched for some months and if you're up to date, you should be
safe.

------
ngcc_hk
May be they should have a class to detail how to debug iOS or macos processes.

