Path Traversal Vulnerability

This information is intended for developers with app(s) that contain the Path Traversal Vulnerability.

What’s happening

Beginning January 16th, 2018, Google Play started to block the publishing of any new apps or updates which contain the Path traversal Vulnerability. Please refer to the notice on your Play Console. After the deadlines shown in your Play Console, any apps that contain unfixed security vulnerabilities may be removed from Google Play.

Action required​

1. Sign in to your Play Console, and navigate to the Alerts section to see which apps are affected and the deadlines to resolve these issues.
2. Update your affected apps and fix the vulnerability.
3. Submit the updated versions of your affected apps.

Upon resubmission, your app will be reviewed again. This process can take several hours. If the app passes review and is published successfully, then no further action is required. If the app fails review, then the new app version will not be published and you will receive an email notification.

Additional details

Implementations of openFile and openAssetFile in exported ContentProviders can be vulnerable if they do not properly validate incoming Uri parameters. A malicious app can supply a crafted Uri (for example, one that contains “/../”) to trick your app into returning a ParcelFileDescriptor for a file outside of the intended directory, thereby allowing the malicious app to access any file accessible to your app.

There are two recommended strategies for eliminating a Path Traversal Vulnerability in a ContentProvider.

1. If your ContentProvider does not need to be exposed to other apps:

• You can modify the <provider> tag of the affected ContentProvider in your Manifest to set android:exported=”false”. This will prevent other apps from sending Intents to the affected ContentProvider.
• You can also set the android:permission attribute to be a permission with android:protectionLevel=“signature” to prevent apps written by other developers from sending Intents to the affected ContentProvider. 

2. If your ContentProvider needs to be exposed to other apps:

You must correctly ensure that inputs to openFile that contain path traversal characters cannot cause your app to return unexpected files. You can do this by checking the file’s canonical path. For example:

public ParcelFileDescriptor openFile (Uri uri, String mode)
   throws FileNotFoundException {
 File f = new File(DIR, uri.getLastPathSegment());
 if (!f.getCanonicalPath().startsWith(DIR)) {
   throw new IllegalArgumentException();
 }
 return ParcelFileDescriptor.open(f, ParcelFileDescriptor.MODE_READ_ONLY);
}

 

Caveats:

1. Note that calling getLastPathSegment on the Uri parameter is not safe. A malicious app can supply an encoded Uri path like %2F..%2F..path%2Fto%2Fsecret.txt so the result of getLastPathSegment will be /../../path/to/secret.txt. For example, the following implementation is still vulnerable to attack.

public ParcelFileDescriptor openFile(Uri uri, String mode) {
 File f = new File(DIR, uri.getLastPathSegment());
 return ParcelFileDescriptor.open(f, ParcelFileDescriptor.MODE_READ_ONLY);
}

 

2. Note that UriMatcher match is not sufficient to sanitize or restrict path patterns ending in * like public/*. A malicious app can supply an encoded Uri path like public/%2E%2E%2Fprivate%2Fsecret.txt and, when combined with getLastPathSegment or getPath, the result will be public/../private/secret.txt

We’re here to help

If you have technical questions about the vulnerability, you can post to Stack Overflow and use the tag “android-security.” For clarification on steps you need to take to resolve this issue, you can contact our developer support team.