Android task hijacking with taskAffinity, Automatically add android:taskAffinity in a new project #63559
Description
Use case
I discovered that Android task hijacking is allowed in a flutter application, any malicious app can put itself on the stack of the flutter application by adding taskAffinity="com.example.myFlutterApp" in the AndroidManifest.xml of the <activity> tag of the MainActivity
Steps to Reproduce
- create a new blank android project, in AndroidManifest.xml add
android:excludeFromRecents="true" android:launchMode="singleTask" android:taskAffinity="{com.example.myFlutterApp}"in the<activity>tag from the MainActivity. - open the
com.example.myflutterappapplication. - run the android app
- close it and open the flutter application again
Expected results:
The flutter application
Actual results:
the android application
Proposal
Automatically add android:taskAffinity="" to the <application> tag in the AndroidManifest.xml of the flutter app
Metadata
Metadata
Assignees
Labels
Type
Projects
- Status
Activity
[-]Android task hijacking with taskAffinity[/-][+]Android task hijacking with taskAffinity, Automatically add android:taskAffinity in a new project [/+]anjalsaneen commentedon May 17, 2021
Anti-virus software can be detected as a malicious app if app id is not the same as task affinity.
18 remaining items
Hixie commentedon Feb 28, 2024
https://www.guardsquare.com/blog/protecting-against-strandhogg has some information that suggests there's more we can do.
johnmccutchan commentedon Feb 28, 2024
The template addresses Strandhogg 1.0
For devices running Android <= 28 it is impossible to protect against Strandhogg 2.0
For devices running Android == 29 you need (1) to protect your app against Strandhogg 1.0 and 2.0
For devices running Android >= 30 your app is protected from Strandhogg 1.0 and 2.0.
mariamhas commentedon Feb 28, 2024
I think its a good idea to point people to the doc that the Android folks are updating about having a minsdk set being the only way to mitigate this issue in our support platforms page.
Android doc: https://developer.android.com/privacy-and-security/risks/strandhogg
johnmccutchan commentedon Feb 28, 2024
Yes, the existing official documentation has a bug in it that suggests setting "targetSdkVersion" is sufficient but it needs to be "minSdkVersion".
One way Flutter could protect its developers is to stop supporting Android < 29
Hixie commentedon Feb 28, 2024
I think it's sufficient to warn people of the problem (not all applications will care about being spoofed). (edit: I mean, as opposed to entirely dropping support for older versions.)
It seems like we should detect apps that don't have the template's mitigation in place, and warn about the problem (is there any useful case where one would not put the mitigation in place? If so we'd need a way to silence the warning, e.g. leaving a comment in the file that says it's intentionally not set).
We could consider what our default minimum should be, maybe with a comment in the file saying that we support down to a particular version but that certain versions have known vulnerabilities, pointing to the relevant documentation.
I agree with @mariamhas that documenting this on our web site's "supported platforms" page is good regardless.
Hixie commentedon Mar 1, 2024
AndroidManifest.xmlfile doesn't contain the stringandroid:taskAffinity.Hixie commentedon Apr 19, 2024
I'm going to close this issue in favor of the ones filed above.
github-actions commentedon May 3, 2024
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.