Thanks to Nagy Ferenc László and Anna Szalay of SophosLabs for the behind-the-scenes effort they put into this article.
Google just put out a surprisingly important patch for the Google Admin app.
If you use any of the Google For Work tools at your business, university or school, this fix is relevant to you.
The Google Admin app is a mobile version of the Google Admin web console, which lets you “manage your Google for Work account on-the-go.”
Actually, it does a fair bit more than managing just your account.
Even if you don’t use the app yourself, someone in your IT department probably does, because it’s actually designed for administrators.
In fact, according to Google Play, it’s not just for administrators, but for what Google calls super administrators, who get surprising corporate power from the app:
- User Management Features - Add/Edit user, Suspend user, Restore user, Delete user, Reset password.
- Group Management Features - Add/Edit Group, Add members, Delete group, View group members.
- Audit Logs - Review Audit logs, Filter logs by admin, date ranges and event types.
- Notifications - Read and Delete notifications.
As you can imagine, this is the sort of app for which Google’s much-vaunted application sandbox is rather important.
Unlike on a traditional Linux desktop (or Windows, or OS X), each Android application runs as a different user, making it much easier to keep apps from peeking at each others’ files.
That, in turn, means that even if you make a bad security decision and install one rotten app, you don’t necessarily spoil the whole barrel.
→ A vibrant, extensive and inclusive app ecosystem is a vital part of how companies like Microsoft, Apple and Google compete for the mobile marketplace, where business, home and pleasure meet. To attract millions of apps in the official marketplace, Google can’t possibly get a thoughtful human to look into both the code and the company behind each one. Yet many users want the freedom to choose widely from apps that are about enjoying a fun lifestyle alongside the more serious issues of work. So they expect to be able to do things like Fitbit, Strava and Instagram on the same device that they use for business email, work documents and official collaboration.
A hole in the sandbox
Ironically, Google Admin turned out to have pierced a hole in the sandbox.
That’s rather a problem, considering that the app is in Google Play’s 500K-1M user bracket, all of whom are not merely admins but superadmins.
Security researchers at MWR Labs found the hole back in March 2015, and advised Google.
Unfortunately, Google was unable to meet the 90-day “investigate and fix” deadline it imposes on itself and the rest of the world via its own Project Zero.
Apparently, Google ended up asking for a bit more time, which still wasn’t long enough.
Whereupon MWR Labs published its advisory [PDF] anyway, much as Google’s project Zero team would have done.
Google scrambled out its fix the very next day.
At first sight, therefore, it looks as though the public disclosure by MWR Labs, for all that it gave away potential attack secrets, had a positive result by getting Google to act where five months of secrecy hadn’t.
This, of course, is why some researchers advocate full disclosure, which where you cut to the chase by telling everyone about the bug in detail right at the very start.
(We disagree, as we’ve said before, and as our official policy makes clear, because we think the carrot-and-stick approach of responsible disclosure tends to help the crooks less.)
The “PINhole” bug
The bug was an interesting one, and it turned up in an intriguing place: a component of the Admin program called ReportPinActivity.
That’s part of the program dedicated to setting up security PINs, making it an ironic place to find a flaw.
Greatly simplified, you could pass the ReportPinActivity routine a URL that it would open as a web page.
No problem, you might think, because the Same Origin Policy says that programs that open web pages should only let those pages use data that you already have access to.
But the MWR Labs guys found that they could use a URL that referenced a local file (i.e. a URL starting file:// rather than http:// or https://) that they did have access to…
…and then change the local file into a symbolic link to a file they weren’t supposed to access, such as a security-related file inside the Google Admin sandbox.
→ Symbolic links are special types of file, supported by all mainstream modern operating systems. Symlinks act much like a web redirect from one website to another. They tell the operating system, “Make this file show up in directory X, but fetch its content from directory Y.” This saves space, because files don’t have to repeated on disk everywhere they are needed. It also simplifies updating, because a change in the physical file automatically “shows up” in every symbolic link, precisely because they’re links, not copies.
Because JavaScript was enabled inside the URL rendered by ReportPinActivity, the researchers were able program a short delay and then simply reload the page.
Apparently, Google Admin didn’t revalidate whether they were still allowed to access the page, because the URL hadn’t changed, so (in theory at least), the Same Origin Policy ought still to apply.
That gave their web page access to Google Admin’s private data, which their JavaScript could then exfiltrate via a web GET or POST request.
What to do?
If you use Google Admin, check that you have the latest version.
According to Google Play [2015-08-18T12:00Z] , you should see something like this:
(We don’t know why the update released on 14 August 2015 still has 20141016 in its version string – we’ll guess that the date reflects the last major functionality change, and the following two digits the latest patch level.)