LAS VEGAS—For Nick Kralevich, head of Android platform security at Google, there is no better barometer for success than finding out the market value for vulnerabilities on the OS he works to protect are among the highest paid for mobile.
During a Black Hat session on hardening Android, Kralevich discussed the multi-year journey Google developers have been on to get to where it is today.
“It’s both frightening and exhilarating at the same time to think Android is running on 2 billion devices today,” he said. And securing them is a big responsibility that has evolved significantly over the years.
For Kralevich, efforts to secure Android are tied to reducing its attack surface. And for the past several years, he said, his team has made significant gains.
“Attack surface reduction means several different things. How do we make sure an application can only do what it is intended to do? How do we minimize the surface that is exposed? How do we contain processes within Android and follow the principle of least privilege?” he said.
The Smalley Report
For a long time Google approached security differently, focusing on exploit mitigations such as fstack-protector and ASLR, and preventing format string vulnerabilities. Then Stephen Smalley published a report “The Case for Security Enhanced Android” in 2012 that was critical of several components of the Android OS that were vulnerable to nearly a half dozen rooting exploits. For Kralevich, the paper struck a nerve, helping him realize that he needed to shift focus on reducing the Android attack surface versus exploit mitigation.
“A lot of us looked at Smalley’s report and said there is something here,” he said. “So we began focusing on attack surface minimization and containment as a model and seeing what we could do.”
Today, he said, every Android process is running in a sandbox that has minimum privileges. “My job is to reduce the attack surface to the point even if there are bugs, those bugs don’t mean anything,” he said. Kralevich calls this strategy architectural separation and architectural decomposition.
The journey from several sandboxes to a multiple containment strategy was long and involved a lot of CVEs – with the chief one being those tied to the Stagefright vulnerability.
“Stagefright was a successful failure. Something bad happened, but in the end something better happened,” he said. He credits Stagefright for being a catalyst for Google’s Android Security Bulletins and hastening its efforts to update the Android ecosystem on a quicker basis.
But, it’s what Stagefright motivated Google to do with the Android Media Stack that is a microcosm of larger Android attack surface reduction efforts.
“In the old model when the bug happened, it happened in the MediaServer process, so an attacker was able to get all the capabilities associated with the process. In Android Nougat, functionality moved to specific processes. The Media Stack now consisted of seven components from MediaServer, MediaExtractor to MediaDrmServer.
A more modern example of architectural separation, Kralevich said, is Project Treble, introduced this year to Android O, Google’s upcoming release of the Android mobile operating system. “At its heart, Project Treble is a defined by strong architectural separation between core Android components that Google creates and vendor customization,” Kralevich said.
Project Treble takes Android containment a step further by separating the hardware-specific drivers and firmware used by companies such as Samsung or Qualcomm from the Android operating system. The implications will be significant when it comes Google’s ability roll out OS patches without having to wait for things such as chipset compatibility. Kralevich explained that the modular approach to hardware and software would also allow Google to limit aspects of the Android framework from accessing a device’s kernel.
Don’t Forget the Kernel
That reduction of the attack surface in the user space has shifted focus by bad guys and researchers alike to focus more on the Android kernel. In 2014, he said, kernel bugs represented 4 percent of reported bugs compared with 39 percent today.
Google blames an uptick in the number of reported kernel bugs to the success of locking down the Android user space making it harder to find vulnerabilities. He added, the introduction of significantly higher bounties for kernel bugs was also a contributing factor.
That spurred Google to apply the surface reduction strategy on the kernel. One of those efforts included looking closer at a system calls to drivers via IOCTLs (input/output control). Fewer IOCTLs equals fewer avenues for bad guys to reach bugs.
So, with the introduction of Android 6.0 (Marshmallow), Google added a new tool called an IOCTL Filter giving developers a way to massively reduce the number of unneeded IOCTLs inside components such as the WiFi radio chipset and the GPU.
“When we took a closer look, we found only a fraction of IOCTL calls were actually being used. So out of the hundreds (of IOCTLs) we were able to turn off the vast majority of them with no functionality loss,” Kralevich said.
In fact, much of the work to reduce the attack surface of the kernel has been stripping down unnecessary functionality. Those efforts to pair back excess functionality will continue with future targets such as getting rid of useless dev files, scaling back proc files and reducing shared data stores.
“Attack surface management is the key for what we need to do in the security space to be secure. Being able to understand your architecture and being able to understand the different moving parts is really important. We have been investing significant time to make sure the Android attack surface is minimal to decrease the probability there will be relevant bugs in Android,” he said.
That way, Kralevich said, his team can do the seemingly impossible – fix bugs before they know about them.
