How Bugs Lead to a Better Android

Google explained during a Black Hat talk its approach to patching Android vulnerabilities and lessons learned post-Stagefright.

Google is used to taking a beating over Android vulnerabilities, but it says too often its hard work fixing vulnerabilities and keeping the platform safe goes unnoticed.

“Over the seven years working on Android security vulnerabilities I’ve seen a lot of bugs and a lot of fear uncertainty and doubt,” said Nick Kralevich, Android platform security team leader with Google. “It seems like often you read in the press that a billion devices are affected by a buggy app. But after the press pipes down you don’t really hear what happens next. You don’t hear about the lessons learned and the things that we do to make Android safer.”

During a talk at Black Hat 2016, Kralevich, who is one of the original founding members of the Android security team, discussed how the Android team springs into action post bug notification and what it does to fix the problem and learn from its mistakes. He said many of the worst Android bugs have led to a significant hardening of Android’s defenses ranging from protecting data in transit, advanced sandboxing and designing safer APIs.

“We invest heavily in learning from vulnerabilities and applying those lessons to new releases,” Kralevich said. “While vulnerabilities will never go away, they can be contained and managed.”

Most notably, Kralevich discussed what he considers one of Android’s biggest “successful failures” – the notorious Stagefright vulnerability. He compares Stagefright to NASA’s failed Apollo 13 mission which successfully returned three astronauts safely home.

“Even though the Apollo 13 mission failed, it was one of NASA’s finest hours and in the same I consider Stagefright to be one of Google’s finest hours,” he said.

Major vulnerabilities in Android’s mediaserver component have pushed Google to go further than just patch bugs and challenged researchers to dig deeper and do things such as ban anonymous executables in memory, restrict loading executable code from outside the system and only allow executables to come from dm-verity protected partitions.

“We say a bug, there was lots of warnings and lots of things happened and we when we got around to it we spent some time really cleaning things up with seven solid mitigations. A lot them were to protect the mediaserver process, but a lot of them were to protect Android as a whole.”

That wholesale rethink of Android continues pushed Kralevich’s team who more recently cracked down on unencrypted and badly encrypted traffic. “Everyone knows the network is not to be trusted. There is still in this world too much unencrypted traffic. We had a big focus on clear text traffic and introduced to features in Marshmallow that address this,” he said.

It was an independent researcher who scanned Google Play library of apps and found 1,414 apps with traffic moving in the clear, or poorly protected. That pushed Google to push out two patches (CVE-2015-5717 and CVE-2015-3610) to reduce risks. “If libraries detect that there is clear text traffic we will go ahead turn off your application,” Kralevich said.

In echoing similar calls for more coordinated efforts between security researchers here at Black Hat, Kralevich said the industry needs to move towards memory-safe languages, “including sacred cows such as the Linux kernel.”

He also urged mobile security experts to join forces to focus together on exploit mitigation, exploit containment, principles of least privilege and overall attack surface reduction.

Topping Google’s list for bug root causes for all of Android (including kernel and other components) include 17 percent tied to heap buffer overs, 13 percent toward integer overflow and 12 percent linked to uninitialized data.

Suggested articles