Page History

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

In the case of the twicca appthe vulnerability in the Twicca app (in versions 0.7.0 through 0.9.30, see the link below), by launching twiccaTwicca'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 a social networking service with the twicca the Twicca user's twitter Twitter account.

Noncompliant Code Example

This noncompliant code example shows an AndroidManifest.xml file for an application that acts on receiving an intent without checking the caller's identityexports 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 caller's identity is checked before any action is takenactivity is not exported:

TBD

Compliant Solution (Setting Permission Requirements)

<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 caller is the same as the package name of itself. If the package names are different, the activity exitsThis compliant solution shows the permissions set in the manifest that prevent a malicious application from triggering an inappropriate action:

TBD

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 following facts, Twicca's solution may be logical and safe against the exploit:

• Only one app with a particular package name can exist on Google Play.
• If a user tries to install an app whose package name already exists on the device, the installation either will fail or will overwrite the previously installed app.

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.

Related Vulnerabilities

• JVN#31860555  Twicca fails to restrict access permissions  

Related Guidelines

Bibliography

Image Added Image Added Image Added