Hello, everyone, and welcome. My name is Lilian.
I'm an engineer with Android Security Assurance
in the Android Security and Privacy Organization.
My team and our associated teams
are responsible for reviewing and reproducing reported vulnerabilities in Android,
whether those are discovered internally
or submitted through the Android Vulnerability Rewards Program.
I am here today to tell you about that VRP.
If you find security issues in Android,
whether that’s in the framework, in the kernel,
in any part of the system, you can send them to us for cash rewards.
The Google VRP was launched in 2010.
It’s paid out nearly $30 million since then.
The program was expanded to include Android in 2015
and is only getting larger.
We've paid almost $8 million for Android bugs alone.
To be clear, it’s not that we’re not looking for security issues from our side.
We do a lot of checks.
Many interfaces that run on untrusted inputs are now subject to automated fuzzing.
The Android Red Team is looking through the most interesting parts of the code.
They are hacking Android from within.
They’re being very helpful for us.
We also have a cadre of Google employees, both within Android and not,
using future Android releases in their daily jobs.
They’ve opted into Log Collection.
We can pick out crashes from those logs
to see what’s going on with devices in the wild,
to see if there’s any potential breaches in daily use.
But that's still not enough.
We're very close to this code.
We look at it all the time.
But Android is an open-source system.
Anyone can look at all of the same code we can.
An outside perspective is going to see all sorts of things that we can’t.
And the more of these bugs we find, the more we can fix.
Every month, we release a new security bulletin.
This has all of the patches that phone makers have to incorporate into their builds
if they want to say they’re keeping our users safe,
to say they’re up-to-date.
To make sure the most important fixes can be released as soon as possible,
we have different severity levels,
depending on the particular danger posed to users.
The worst ones are critical.
They account for 13% of the patches we released in the last year of bulletins.
These are the vulnerabilities that a skilled attacker could use
in things like code execution in the secure element,
things like a remote compromise of the kernal or of the system process, things like that.
The next level is high.
These are the majority of our monthly fixes.
High severity vulnerabilities can be leveraged into things
like local compromise of the kernel or of the system server,
things like reading private data from other users or from other apps,
or for a lock screen or a secure boot bypass,
or any bypass of privacy and security settings.
After those, we have moderate severity.
This is for more general bypasses of user interaction,
or for breaking constraints on restricted processes,
or for other violations of our defense-in-depth tactics.
Most moderates are fixed in major version releases,
rather than the monthly bulletins.
We also have severity modifiers for bugs
that require root access or other privileges to exploit.
So bugs can be rated lower than moderate.
Researchers are still rewarded for low-severity bugs,
but those bugs are not generally given CVEs
and they're fixed in our annual version releases.
We do, of course, publish our severity guidelines.
You can look those up on our website.
We update them every year to clarify them,
to adapt to any new angles that researchers might be showing us.
And, of course, there’s money for it.
There's recognition for it.
We issue CVEs for these bugs with the reporters’ names or pseudonyms.
If you can provide us with an exploit chain that breaches the Titan M --
That’s the secure computation chip in our Pixel phones --
that chain could be worth as much as $1 million.
It could be worth even more if it works on a preview version of Android.
Breaching the kernel or the system server could be worth $250,000.
Even breaking through the lock screen can get you up to $100,000.
We've paid out nearly $8 million over the course of the program,
including over $900,000 just in 2021.
And I would like to see that number increase.
Most of the bugs we get are, in all honesty, pretty straightforward.
Code is running in a privileged process, like the kernel or the system server.
It has a race condition or a missed bounce check.
Some memory gets corrupted,
and the attacker can take control of that process and run their own code.
None of these bugs stand out above any of the others,
but each one is a small vulnerability.
Those vulnerabilities add up.
And the rewards for those add up.
Each of these CVEs came with a cash reward to an external researcher.
And each of these fixes made your phones that much safer.
But they’re not what I’m here to talk about.
What I have for you today is five of my favorite bugs
that we’ve fixed in the last year.
These are the bugs that really made us sit up and say, wow!
Well done for finding that!
We should really make sure you get rewarded and that bug gets fixed.
Our first bug today shows a conflict we’ve had since the beginning of computing,
between security and style.
UI designers love transitions like this.
They make the system feel a lot smoother, a lot less sterile,
a lot more comfortable for users.
That's important.
We give developers a lot of powerful tools to control these transitions.
But it turns out we didn’t quite think through
the possible consequences of that power.
As soon as the transition starts,
the next app is considered foreground and in focus.
This becomes a problem when the transition is slow enough
that the user might not notice it.
What’s the worst that could happen with that?
The next screen might turn on Bluetooth for a remote attack.
It might grant the attacker permissions you didn’t want to grant,
like location or camera.
The next screen might even be the camera itself,
taking pictures you didn’t want to take.
Tricking someone into actions like that goes against our principle of user consent.
And we consider this a high severity escalation of privilege.
Next up, we have a vulnerability in another important Android system,
one that developers need to be paying attention to,
and that's accessibility.
Not everyone can see very well.
Not everyone has the dexterity to touch precisely where they intend to.
And we don’t want that to prevent anyone from using their phones.
We have the tools to help them.
An accessibility service is designed to help out with all of these things.
We provide a default accessibility service.
Users can also install third-party services from the Play Store.
The selected service runs in the background, but it has special permissions and access
to read anything on the screen, which is, well, everything.
It can also send touch events to the screen.
So it can provide all the help a user needs with typing, with using buttons,
with hitting very small checkboxes, all of that.
And that includes, of course, reading notifications.
We also have a feature that controls what actually shows up on the lock screen.
There are some notifications that you don’t really want available
until you’ve unlocked your phone.
Some notifications are fine.
You might get weather reports.
You might get news headlines.
You might get gentle reminders to stretch or to drink water.
Things like that aren't really private information.
Most notifications are more sensitive than that.
And that’s the thing that developers need to keep in mind.
How bad would it be if a stranger saw this notification?
You don’t want just anybody who picks up your phone
to read your banking information.
Messaging apps in particular can have a lot of sensitive data.
Even if you don’t consider things like two-factor authentication,
most messages you get are supposed to be very private.
Unfortunately, when notifications were coming in when the screen was locked,
the accessibility service was getting a bit too enthusiastic about being helpful,
and it was reading the full contents of each one
without checking if that text was actually supposed to be available.
What did this mean?
It meant the accessibility service was leaking information
that was supposed to be hidden by the lock screen.
We consider this a high severity information disclosure.
Before we get into this next bug,
a very quick mention of how Android handles multiple users.
We have a couple different use cases here.
First, of course, multiple people might share a device.
Housemates could share a tablet.
A parent might lend their phone to their child.
We also allow users to set up work profiles on their phone.
A work profile gives you the ability to run all the apps that your employer needs,
in an environment they control, while keeping your personal data
out of reach of the administrator of that environment.
We basically treat them as separate users.
Meanwhile, at the application level,
there are very few reasons for one app
to be aware of any user other than the current one.
We do have a permission for that.
It’s called Interact Across Users,
but that’s only available to highly privileged apps.
So imagine our surprise when we heard
that some screenshots were being saved as the wrong user.
In particular, this was only happening
when taking a screenshot shortly after switching users.
It turned out that the screenshot service wasn’t paying as much attention
as it might have to user switches.
So these were being handed back to the previous user.
Oops!
Imagine having bought a birthday present for your child,
taking a screenshot of the receipt,
and then your child finds out about the gift from the screenshot.
We consider this a high severity information disclosure.
And then there's permissions.
With all the extremely personal information that a phone can gather and keep,
we want apps to be very specific about what they can access,
but the more granular we make these permissions,
the more often an application has to interrupt the user.
We solved this by adding permission groups.
So granting one permission in a group
automatically grants all the permissions for that group.
These are almost entirely used for normal level permissions.
These don't protect anything particularly sensitive.
Any permission that doesn’t have a group is placed in the undefined group.
Unfortunately, there was a problem with these in an older version of Android.
An app could start out by creating its own custom permission
in no particular group.
That permission could be marked as dangerous,
but, of course, we automatically grant an app all of its own permissions.
If that app was later updated to move that permission
into the undefined group, the system would then move
all of its own permissions to the undefined group as well.
While this only applied to that one app itself,
it still allowed that app to access things like location, like camera,
like text messages, all without the user's consent.
We consider this a high severity escalation privilege.
Then there are some bugs that are, simply put, terrifying.
These are sobering reminders that our work has direct real-world consequences.
They’re, thankfully, rare, but when we do find them,
it is an absolute dash to get them fixed.
If you’ve ever written a location-aware app,
or maybe you've looked into how to play certain games
without having to leave your couch, then you know about mock locations.
It’s much easier to write an app if you don’t have to travel to debug it.
We do support that.
Because this is intended for developers,
data coming from the mock location provider has to be marked as fake.
So apps in Release mode can ignore that data;
however, we have another use for location data,
and that is calling emergency services.
When you make that call from a mobile phone,
your location is sent to the operator,
even if you're too panicked to explain where you are.
That makes sure responders can deploy to the right place.
It is absolutely necessary that this data is reliable.
We found out that the mock location data was being sent to the modem.
It was being sent to emergency services as real data.
If you’ve ever gotten the attention of the wrong parts of the internet,
you know what could have happened with this.
There’s an attack called swatting
that abusers have adopted over the last several years
where an attacker makes a dire-sounding call to the police
in an attempt to get a fully armed response team to a victim’s home.
The ability to make this call with fake data would have made this far, far too easy.
This was handled as a high severity escalation of privilege.
And I’m at least happy to say that this was the fastest
I have ever seen a bug go from report to fix.
And that is as bad as it gets.
That’s why I do this job,
and I need your help.
These bugs were all found by reporters outside of Google.
They were sent to us through our VRP website,
bughunters.google.com.
Once again, that’s bughunters.google.com.
And the bugs we accept are not exclusive to Android.
If you’ve found a security vulnerability anywhere in a Google product, let’s talk.
And I really do mean, let’s talk.
We have the largest ecosystem of bug hunters
because we work with researchers throughout the process
of analyzing these bugs.
We make sure to confirm our assessment in case we missed something.
We accept patches from researchers to help fix all this.
We issue CVEs in the name or the pseudonym of the discovering researcher;
furthermore, if a researcher decides to forego their reward,
they can donate the money to the charity of their choice.
And Google will double that amount.
And with that, I want to say, thank you.
Thank you for helping us make Android the safest operating system we can.
I’ll see you in the bug reports.