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 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 a social networking 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:
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
<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> |
androidandroid: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:
...
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 caller is the same as the package name of itself. If the package names are different, the activity exits:
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
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 thatfollowing facts, Twicca's solution may be logical and safe against the exploit:
- Only only one app with a particular package name can exist on Google Play; and .
- if If a user tries to install an app whose package name already exists on the installed appsdevice, 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.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
DRD09-J | High | Probable | Medium | P12 | L1 |
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
4.1.1.1 Creating/using private activities |
Bibliography
[Chin 2011]Analyzing Inter-Application Communication in AndroidJSSEC 2014] | 4.1 To use and to make an activity |