MIAMI— What is life like in the security trenches inside Google’s Chrome browser security team? From the perspective of Justin Schuh, lead engineer of Chrome Security, it’s balancing act where he has to juggle OEM pressures, questionable certificate authorities and quashing third-party software incompatibility issues.
“There are a lot of different things in play when it comes to Chrome security most people never consider,” Schuh said during a keynote talk at the Infiltrate Conference.
There are the obvious, such as the diverse numbers of platforms Chrome needs to support. But, then there is the not so obvious, such as OEM shovel-ware, unreliable certificate authorities, outdated software and browser plugins that have created major headaches for Schuh’s team.
“Just when you think you’ve figured it all out, then it’s like a monkey with a chainsaw comes in and tries to break everything up… The user has no idea why Chrome isn’t working. It’s just our fault from their perspective,” he said.
For those reasons, his security team is forced to spend much its daily grind working to snuff out security problems on multiple fronts he calls browser “friendly fire.” These well intended, but poorly executed bits of code are the bane of his existence.
“Friendly fire is really all this third-party garbage that runs in our systems. It’s evasive stuff that gets bundled or injected into applications on your machine,” Schuh said. “This is the stuff I actually worry about and get frustrated by the most.”
OEM features added to an OS, he said, are too often poorly designed, seldom updated in a timely manner and can create instability within Chrome. “I really don’t know why they call them value-adds, because that is the most misleading name in the world. This is shovel-ware.”
Next, Chrome breaks and Google is blamed, explained Schuh. “Users don’t know that it was that software the EOM put on their machine or that fun little utility was the culprit. We have had instances where a Bluetooth manager was leaking stuff into sandbox processes,” he said.
In another example, he said an Android device maker’s poor software implantation of the seccomp-pbf (secure computing mode) – used by a number OEMs and third-party app developers – created a Linux kernel panic triggering an “extremely” trivial exploitable memory corruption vulnerability.
“This is the kind of stuff we have to deal with every day,” he said.
Certificate authorities are another source of “friendly fire”.
“It gets a little scary when you realize there are thousands of intermediate CAs out there. Any one of them can essentially sign a cert that potentially bypasses the root system,” Schuh said.
The wakeup call for Chrome Security was in 2011 when certificate authority DigiNotar was breached allowing attackers to us DigiNotar’s system to issue more than 500 fraudulent digital certificates for domains such as Google, Mozilla, and Skype.
“This got our attention. DigiNotar was relatively small, but it was able to impact so many websites. That was a really eye-opening event that changed how we fundamentally look at CAs,” Schuh said. “After that, we started monitoring CAs very closely. What we found was there is a lot of shenanigans going on.”
He said every couple months his team finds a major issue where there is a CA is miss-issuing for properties they shouldn’t.
Schuh said Google’s solutions has been enforcing shorter CA issuances, HTTP public key pinning and demanding more certificate transparency. “We aren’t making a lot of new friends. But we are willing to take the hit because DigiNotar shows it’s necessary.”
Another headache is tackling challenges around version updates of security software after a license has expired. He cited several examples where Chrome has rolled out new security features only to have them conflict with older versions of security software and generate elevated levels of Chrome errors.
“The problem is, those people who aren’t paying don’t appear to be getting (software) updates or didn’t get the latest patch,” he said.
There is hope, Schuh said. One unmitigated success was the sun setting of NPAPI plugins. In 2014, Google announced it would remove NPAPI support from Chrome, a change, he said, that improved Chrome’s security, stability as well as reduce complexity in the code base.
“There was a lot of resistance, but removing NPAPI was unqualified success. Ripping it out reduced the Chrome threat landscape considerably,” he said.
