There’s common, mistaken assumption that any software bug can be turned into a security exploit. In fact, most bugs aren’t exploitable and there are many things Android has done to improve those odds. We’ve spent the last 4 years investing heavily in technologies focused on one type of bug -- memory corruption bugs -- and trying to make those bugs more difficult to exploit.
A list of some of those technologies that have been introduced since since Ice Cream Sandwich (Android 4.0) are listed here: https://source.android.com/devices/tech/security/enhancements/index.html
The most well known of these is called Address Space Layout Randomization (‘ASLR’), which was fully completed in Android 4.1 with support for PIE (Position Independent Executables) and is now on over 85% of Android devices. This technology makes it more difficult for an attacker to guess the location of code, which is required for them to build a successful exploit. (For the layperson — ASLR makes writing an exploit like trying to get across a foreign city without access to Google Maps, any previous knowledge of the city, any knowledge of local landmarks, or even the local language. Depending on what city you are in and where you’re trying to go, it might be possible but it’s certainly much more difficult.) But we didn’t stop with ASLR, we’ve also added NX, FortifySource, Read-Only-Relocations, Stack Canaries, and more.
Like most advanced security technologies, we’re always assessing the effectiveness of these new approaches, and looking for ways to refine them to better protect users. We know that some bugs are simply not exploitable, even without exploit mitigation. We know these technologies make exploitation more difficult — and that in some instances that they make exploitation impossible. But the research community today is incentivized to find lots of bugs rather than to test exploit mitigation technologies, so it can be difficult to know if exploitation of bugs is actually possible.
So, to help test these technologies, we designed the Android Security Rewards [ https://g.co/androidsecurityrewards
] program to strongly incentivize researchers to actually prove that an issue is exploitable. We will pay up to $30,000 for developers that provide working remote exploits against current Nexus devices. So far we have had a few issues filed as security bugs, but haven’t had anyone submit an exploit in an attempt to be paid via Android Security Rewards. (Some people warn me that it’s tempting fate to make that statement. But that’s not true: this is an intentional request for researchers to start testing those defenses. We want to know about when Android’s exploitation mitigation works, and when it doesn’t work. So I hope this will result in an exploit being presented. The sooner we know about it, the sooner Android users will get better protections.)
Of course, if there is any chance that an issue might be exploitable, we’ll quickly provide a patch for the issue to our partners, to our Android devices, and to the public via the Android Open Source Project.
But updates are truly a last resort. They should be neither the first nor the only step in a multi-layered stack of security technology. I’m optimistic that advanced exploitation mitigation technology in Android will help us to move beyond the period of time when fast patching was the only solution available to secure devices. And I look forward to more research into how these technologies can be used to prevent exploitation on Android and other platforms.