Edge Cases to Keep in Mind. Part 3 – Time of Check to Time of Use Race Conditions in Android UI

In this article, we’ll show how race conditions affect Android runtime permission system.

If you are a developer you’ve probably heard about race conditions. They are often associated with concurrent background operations performed in the fractions of seconds. However, certain race conditions may also appear in UI and last for the infinite time. In this article, we’ll show how race conditions affect Android runtime permission system.

This is the third article about “Edge Cases to Keep in Mind”. Below you can find other blog posts from the series:

Edge Cases to Keep in Mind. Part 1 – Text

Edge Cases to Keep in Mind. Part 2 – Files

Race condition & Time of check to time of use – what does it mean?

Firstly, we need to explain some basic terms.

Race condition occurs if multiple operations occur at the same time and their order affects the result. A textbook example is two threads incrementing the same variable. It seems to be trivial, however, usually, we need to use special, thread-safe elements to implement it properly.

Time of check to time of use (TOCTTOU or TOCTOU, pronounced TOCK too) is a specific kind of race condition where a performed operation is preceded by state checking and that state is modified in the time between a check and actual execution. It is often illustrated by checking user privileges at the login time only. For example, if you are an administrator at the moment when you sign in and you can use your privileges until you sign out, even if your admin access is revoked in the meantime.

Android runtime permissions

Let’s also summarise Android runtime permissions basics.

Starting from Android 6.0 (API level 23) the most dangerous permissions has to be explicitly granted by a user at runtime rather than all at once on app installation time. The most noticeable element here is a system dialogue with DENY and ALLOW buttons like shown in figure 1.

After clicking on DENY button we receive PERMISSION_DENIED in onRequestPermissionsResult callback and we should disable the functionality that depends on this permission. According to the official snippet.

Additionally, user can also grant or deny permissions by using App permissions screen in application settings. You can see that screen in figure 2.

Edge cases are everywhere

Most of you may think that runtime permission denial is a super simple feature and there is no element which can be broken. Well, nothing could be further from the truth!

A dialogue appears only if permission is not granted. So we have the time of check just before displaying a dialogue. And time of use when DENY button is clicked. A period between them can last forever – user can open a dialogue then press home or recent button to move the task with the app to background and return anytime later.

Let’s check if runtime permission dialogue is vulnerable to TOCTTOU. To do so, we can create a super simple activity which checks actual granted permissions after returning from the dialog. Note that apart from standard onRequestPermissionsResult arguments check we’ll call Context#checkSelfPermission() to obtain current permission grant status. Don’t forget to set targetSdkVersion to 23 or higher. The code should look like this:

Now we can perform a test. To do that we need a device or AVD with Android 6.0 (API 23) or newer. Test result is shown on figure 3.

We can see that results differs. onRequestPermissionsResult argument is not valid. So DENY button is not denying anything! It simply does nothing with permission status but returns denied results to app.

Wrap up

It is important to keep timing into account when checking various things in the code. Caching check results may cause bugs and weird effects. TOCTTOU vulnerability does not depend on either platform or programming language so it has been classified as CWE-367.

Related posts