Google on ‘Stagefright” exploit: not all Android bugs are this bad, thanks to Google’s security measures

Bugs may be endless, but that doesn’t mean they are harmful… at least not all them are. Lead engineer Adrian Ludwig made sure to touch on this subject after the whole ‘Stagefright’ exploit was discovered by the media. This vulnerability is said to leave about 95% of Android users exposed to hackers, who could gain access of your handset by simply sending you an MMS message with a malicious file.

As expected, this was a major cause of distress for the industry and all Android users, but Ludwig took it to Google+ to tell us we shouldn’t worry too much, as they are working on this issue and not all bugs are like this one. In fact, it’s amazingly rare to find similar exploits, as Google takes several precautionary measures to make sure your device is protected. Let’s go through some of the most important ones.

ASLR – Address Space Layout Randomization

ASLR is a security technique that shuffles code location, making it harder for hackers to predict it. The system hides memory addresses and these values then have to be guessed.

“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” -Adrian Ludwig, Android security lead engineer

non-PIE linker support removal

ASLR and PIE (position-independent executables) work together, allowing for memory location-based protection. Since Android 5.0, non-PIE content is no longer supported. This makes it harder for any attacker to make its way through the code and find what he needs in order to build an exploit.

NX – No eXecute

Google introduced NX with Android 2.3. Essentially, this is a technology used in CPUs, which seclude memory areas and limit the way code is executed. In Android, it mostly protects the stack and heap.

Fortify Source

Fortify Source is a security method that allows the system to recognize when too many bytes are being copied from a source to its destination. Hackers are known to copy more bytes than usual when they want to overflow a buffer. If such an event were to occur, the system can stop the process. In Android, all code is compiled with these protections.

RELRO – Read-Only-Relocations

Read-Only-Relocations protect internal data sections from being overwritten, in case of a bss or data overflow. It gains control over software execution flows, making attackers harmless in many ways.

And more!

Google has been working hard to keep Android secure. Even if some vulnerabilities come up here and there, Google is confident most people will be fine. More issues start arising when you unlock certain root capabilities and manage to get attacked, but not as many people ever tinker with their smartphones in that way.

But are you really safe?

We would be lying if we told you there isn’t some risk of being hacked, despite all these security measures. The truth is, Android is the most popular mobile OS in the world. When an operating system becomes so popular, hackers start working, and we aren’t seeing an exception here.

According to Eset, Android Malware increased by 63% in 2013, compared to 2012. So did the malware families for Android. The numbers are more modest when we compare 2014 to 2013, but a 25% increase in infections (according to Alcatel-Lucent) is still a significant rise.

This is why we urge you to be smart with your devices. Try not to have MMS auto-download activated, don’t install apps from unreliable sources and make sure not to dig into weird websites. Meanwhile, Google does continue to try and improve security matters by asking for help from the developer community, which has always been the foundation of this glorious operating system.

In an effort to discover possible exploits, Google is willing to offer a monetary reward to those of you who discover a vulnerability. The cash amount will depend on the severity of the hack, but Ludwig does state the Search Giant will pay up to $30,000 to anyone who provides a working remote exploit against the Nexus 6 or Nexus 9.

Adrian Ludwig goes on to mention there have been no attempt to claim the Android Security Rewards, which is a bit reassuring for users. It might also be a challenge to our beloved developers. If you are up for the challenge, just visit the Android Security Rewards page and learn all about the program.