DRD09-J: Restrict access to your sensitive activity

On Android, declaring an intent filter for an activity in the AndroidManifest.xml file means exporting the activity to other apps. If the activity is intended solely for the internal use of the app and an intent filter is declared, any other apps including malware can activate the activity for unintended use.

In the case of the Twicca app, by launching Twicca's activity, another app that does not have permission to access the SD card or network could upload images or movies stored on the SD card to an SNS service with the Twicca user's Twitter account.

Noncompliant Code Example

This noncompliant code example shows an AndroidManifest.xml file for an application that exports the activity to other apps, but does not restrict access to its sensitive activity:

<activity android:configChanges="keyboard|keyboardHidden|orientation" android:name=".media.yfrog.YfrogUploadDialog" android:theme="@style/Vulnerable.Dialog" android:windowSoftInputMode="stateAlwaysHidden">            
	<intent-filter android:icon="@drawable/yfrog_icon" android:label="@string/YFROG">
		<action android:name="jp.co.vulnerable.ACTION_UPLOAD" />                 
		<category android:name="android.intent.category.DEFAULT" />                 
		<data android:mimeType="image/*" />                 
		<data android:mimeType="video/*" />             
	</intent-filter>         
</activity>

 android:name refers to the name of the class that implements this activity. The name of the package is "jp.co.vulnerable" so the fully qualified name of the class implementing this activity is jp.co.vulnerable.media.yfrog.YfrogUploadDialog. Since the intent filter is defined, this activity is exported to other apps.

Compliant Solution (Do not export activity)

In this compliant solution the activity is not exported:

<activity android:configChanges="keyboard|keyboardHidden|orientation" android:name=".media.yfrog.YfrogUploadDialog" android:theme="@style/ VulnerableTheme.Dialog" android:windowSoftInputMode="stateAlwaysHidden" android:exported="false">     
</activity>

By declaring android:exported="false" for an activity tag in the AndroidManifest.xml file, the activity is restricted to only accept intents from within the same app or from an app with the same user ID.

Compliant Solution (Twicca)

This vulnerability was fixed in Twicca v0.9.31. Instead of declaring the activity exported="false" in AndroidManifest.xml, Twicca fixed this vulnerability by validating the caller of this activity. In the onCreate() method of the activity class, code was added to check if the package name of the callier is the same as the package name of itself. If the package names are different, the activity exits:

public void onCreate(Bundle arg5) { 
	super.onCreate(arg5); 
	... 
	ComponentName v0 = this.getCallingActivity(); 
	if(v0 == null) { 
		this.finish(); 
	} else if(!jp.r246.twicca.equals(v0.getPackageName())) { 
		this.finish(); 
		} else { 
			this.a = this.getIntent().getData(); 
			if(this.a == null) { 
				this.finish(); 
			} 
			... 
		} 
	}
}

An Android developer can arbitrarily choose a package name, so different app developers could choose the same package name. Therefore, it is generally not recommended to use the package name for validating the caller of the activity. [JSSEC 2013] The recommended alternative is to check the developer's certificate instead of the package name.

However, considering the facts that

• only one app with a particular package name can exist on Google Play; and  
• if a user tries to install an app whose package name already exists on the installed apps, the installation either will fail or will overwrite the previously installed app;

 Twicca's solution may be logical and safe against the exploitation.

Risk Assessment

Acting on receipt of an intent without validating the caller's identity may lead to sensitive data being revealed or to denial of service.

Automated Detection

Automatic detection of the receipt of an intent is straightforward. It is not feasible to automatically determine whether appropriate checks are made of the caller's identity or whether appropriate permission requirements have been set in the manifest.

Bibliography