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. In stead of declaring the activity to exported="false", twicca fixed this vulnerability by validating the caller of this activity. In onCreate() method of the activity classs, code is added to check if the package name of the calling is the same as the package name of itself. If they 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(); } ... } }
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 |
---|---|---|---|---|---|
DRD06-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.
Bibliography