Closed Bug 1147265 Opened 5 years ago Closed 4 years ago

Tap Jacking attack on android mozilla browser

Categories

(Firefox for Android :: General, defect)

All
Android
defect
Not set

Tracking

()

RESOLVED WONTFIX
Tracking Status
firefox42 --- affected

People

(Reporter: kaleemshaik786, Unassigned)

References

Details

(Keywords: sec-moderate)

Attachments

(5 files, 1 obsolete file)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:36.0) Gecko/20100101 Firefox/36.0
Build ID: 20150305021524

Steps to reproduce:

UI Redressing (Tap jacking) attack may trick users into tapping a specifically crafted malicious App popup window (e.g. toast view), making it a gateway for varied threats such as framing attack. Using this technique, a malicious App could potentially trick a user into making purchases, clicking on ads, installing Apps, or even wiping all of the data from the phone

Android Mozilla browser client do not have protection for button tags.So attacker can obscure another window on top of the button can do malicious actions.

To reproduce the steps
1.First you need to analyse whether the button tags have some special property or not
2.Use apktool.jar and decompile the app
3.Go to the layout folder and analyze button tags with a property filetoucheswhenobscured=true




Actual results:

Attacker can obscure on top of window and make the user tap and perform un intended actions.
I have created a POC Where I have removed the account successfully for syncing data.Attacker can do whatever he wants.A malicious application installed in the device can perform this action.

I am attaching the POC video and eclipse project you can import and reproduce the issue. Please see the video 
Video URL
https://www.dropbox.com/s/0zk1m5xhjtc6y25/Mozilla%20Tap%20Jacking.mov?dl=0

You can read more about tap jacking attacks here

https://www.blackhat.com/docs/asia-14/materials/Niemietz/Asia-14-Niemietz-UI-Redressing-Attacks-On-Android-Devices-Revisited.pdf


Expected results:

Remediation:
1 . 'android:targetSdkVersion' should be 2.3 (API 9) and above, as Android does not provide any protection mechanism below API 9.
2 . Protection mechanisms can be implemented through Java (source code) or layout (xml files). For Java, use the following method:
'setFilterTouchesWhenObscured()' or,
For Layout files, use following method: 'android:filterTouchesWhenObscured' in Button tag located inside layout files.

Sample Code
<Button
android:id="@+id/button1"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_alignLeft="@+id/textView1"
android:layout_below="@+id/textView1"
android:layout_marginLeft="54dp"
android:layout_marginTop="20dp"
android:text="chat heads"
android:filterTouchesWhenObscured="true"/>
Component: Untriaged → General
Product: Firefox → Firefox for Android
Version: 36 Branch → unspecified
Severity: normal → critical
Severity: critical → normal
Flags: sec-bounty?
This attack requires the user to have a malicious app already installed on the phone, correct? Not that that's much protection -- the marketplace is filled with crap apps and a user might be happy to experiment with an interesting-looking unknown if it didn't request too many permissions--but it does limit the velocity/spread of such an attack in the wild.

As of January 2015 we dropped support for Android 2.2 so we should be able to take advantage of setFilterTouchesWhenObscured(). Why the hell isn't that the default Android behavior for all apps? Is it ever a good idea to poke at things you can't see?
Status: UNCONFIRMED → NEW
Ever confirmed: true
I find the do whatever they want to be a dubious claim. They can do whatever we have exposed UI for in our settings. 

I doubt that this can lead to app installs for the release population. Android has a preference for 'Unknown sources' though it is several clicks deep in OS dialogs. If the Android OS dialogs are vulnerable to clickjacking that is something to report to Google.
OS: Mac OS X → Android
Hardware: x86 → All
Hi,
Google is aware of this issue. To prevent this we need to set setFilterTouchesWhenObscured=true for all the button tags in layout xml file or in java code use this class.

This attack is same as clickJacking in web app. The user just need to tap on insecure app he does not require extra permissions also..
Please let me know if you require more info on this.If you want to reproduce the issue just import the eclipse project which I had shared to you.
(In reply to kaleemshaik786 from comment #4)
> Google is aware of this issue.

Is there a public bug opened for this issue? I'm wondering what Google's solution will be, how quickly it'll come, and what number of devices it'll be ported to.

As for fixing this on our end, all Android views might inherit from a single default base style (e.g. "Widget") so we might be able to override that and get an easy win by setting this true for all of our views. It could get more challenging if we also have to include this inheritance in all of our custom styles (because we certainly don't right now). 

However, I wonder how setFilterTouchesWhenObscured=true affects usability of Firefox as a background app - does the View in particular need to be actively drawn over to be considered obscured? Or if any part of Firefox is drawn over are all of Firefox's Views considered obscured? It would be a shame if it was the latter. The documentation [1] implies that the latter is the case:

  When set to true, the view will not receive touches whenever a toast, dialog or other window appears above the view's window.

So does this mean Firefox becomes temporarily uninteractive if we show system toasts or dialogs? That's unfortunate - we'd have to reimplement system toasts and dialogs (never mind when the system draws over Firefox).

CC mhaigh so he's aware of this bug and it's potential effect on the tab queue work (bug 1112185).

[1]: https://developer.android.com/reference/android/view/View.html#attr_android:filterTouchesWhenObscured
Hi Michael,

Thanks for writing. I could not find any open bug for this issue. As mentioned in the link by google  When set to true, the view will not receive touches whenever a toast, dialog or other window appears above the view's window it might happen.

I have read some more blogs on this and a good book I found is"The busy coders book for advanced android development". Pls see the page no 558 for tap jacking issue and how to resolve this

http://commonsware.com/AdvAndroid/AdvAndroid-2_6-CC.pdf

However, in the above link they mentioned it is resolved in 4.0.3 and later but I could not find any google reference that states that, and I successfully bypassed it in your app.

For POC I have used a framework which does not require any permission(Zero Permission). You can find it in the below link
http://blog.seguesec.com/2012/11/android-tapjacking-vulnerability/(Pls Read)
Hi,

Please provide me an update on this..

Thanks,
kaleem
Hi,

Please let me know any progress on this..


Thanks,
Kaleem
(In reply to kaleemshaik786 from comment #9)
> Hi,
> 
> Please let me know any progress on this..

Progress will appear in this bug. Please watch it for updates.
Can you assign this security bug to a dev to work on?
Flags: needinfo?(mark.finkle)
What's the fix? Set setFilterTouchesWhenObscured=true on every tappable element?

I'm fine with starting some experiments, to see what happens if we add setFilterTouchesWhenObscured=true to the main menu (3 dot button). We have other higher priority work in the pipeline, so I have no ETA for this bug.
Assignee: nobody → michael.l.comella
Flags: needinfo?(mark.finkle)
I could think of only two solutions. Either implement "setfilterToucheswhenObscured=true" for button tags in layout->xml files or write this in the code for buttons

public class MyActivity extends Activity {
    protected void onCreate(Bundle bundle) {
        super.onCreate(bundle);

        final Button myButton = (Button)findViewById(R.id.button_id);
        myButton.setFilterTouchesWhenObscured(true);

        myButton.setOnClickListener(new View.OnClickListener() {
            // Perform action on click
        }
    }
}
Dear Mike,

Kindly Provide update on this 

Best,
Kaleem
Hi, Kaleem.

I've been working on a few higher priority bugs which are mostly fixed now. Hopefully I will be able to get back to this within the next week.

Thanks for keeping on top of this! :)
Hi Mike,

Thank you so much for the update.. Will wait for next week :)
I have repro'd with the tap jacking framework and have prevented the tap jacking both programmatically and in XML.

In the end, we have to set filterTouchesWhenObscured on everything. Since we have many Views and are likely to add many more, putting this on Views by hand is error-prone and not ideal. Therefore, we should inherit from styles. We could inherit from a single style with the filterTouchesWhenObscured, but then we lose the ability to inherit from the Android defaults.

Thus, the better approach, imo, is to have several base styles that have filterTouchesWhenObscured="true":
  * which inherit Android base styles and our views which inherit from the base styles inherit from.
  * which inherit from nothing and our views which inherit from nothing inherit from

However, our styles/themes are currently a bit messy and this may not be simple (or just extremely time consuming) – perhaps a better v1 would be to set filterTouchesWhenObscured only on the views which can have dangerous side effects – e.g. remove account, the web content view, the url bar, etc.

Additionally, I think the tap jacking framework can only open Activities we export so if we can limit the access to later Views, we only have to protect the initial Views in our Activities. Note to self to investigate whether non-exported Activities can be accessed.

This could break as new Activities (e.g. tab queue!) are exported.

Concerns: perf – how does this affect inflation times? We can use autophone to check pageload changes.
As you mentioned that is good idea to apply tap jack protection only on sensitive actions rather than applying the whole app.

Tap jacking framework can only be used if the other app activity is exported. I was checking some other POC created by MWR labs here is the link 

https://github.com/mwrlabs/tapjacking-poc/tree/master/src/com/example/tapjacking

Which they explained differently using long toast.

Here is the book I was reading mobile application hackers handbook

https://books.google.co.in/books?id=UgVhBgAAQBAJ&pg=PA267&lpg=PA267&dq=tapjacking+attack+mobile+hackers+handbook&source=bl&ots=SWx5u9dcMZ&sig=PWSCe7YEgIAzLYvY51u4rTdCBcI&hl=en&sa=X&ved=0CB0Q6AEwAGoVChMIu6j_77LbxgIVhVU-Ch0MpQSv#v=onepage&q=tapjacking%20attack%20mobile%20hackers%20handbook&f=false
I found a better solution: we add filterTouchesWhenObscured to the android:theme to our application (preferred because it requires no overhead, but may overwrite the themes specific to each activity), or to each of our activities' themes.
This will affect any activities that do not inherit a theme, which is currently
none of them.

Note that this may affect default inheritance (e.g. we'll no longer inherit
from Holo, if it's the default) but I haven't done the research. To fix it,
you'd have to make the FilteredTouches theme inherit from the default theme
(which could be different for each API level).
All old sync activities inherit from SyncTheme, which inherits from Gecko on
API < 11 and Gecko.Dialog -> GeckoBaseDialog on v11+.

All fxaccount activities inherit from FxAccountTheme, which inherits from
Gecko.

Note that I don't have an old sync account so I did not test that behavior.
Attachment #8633744 - Attachment is obsolete: false
Attachment #8633744 - Flags: review?(mhaigh)
Attachment #8633745 - Attachment is obsolete: false
Attachment #8633745 - Flags: review?(mhaigh)
These patches are fairly simple and can be uplifted - there are no negative effects to applying "filterTouchesWhenObscured" to Views. However, I can't guarantee if the styles have changed in earlier versions and thus if all edge cases are covered, but I doubt the styles have changed so much that we won't be in large part protected.
The Draw Over Other Apps permission does not appear to be affected by these changes (yay, tab queues!). I think the reason this is okay is that Views in a draw-over-other-apps scenario don't release touch events to the underlying application (at least in my brief playing around) - I tested using Facebook chat heads.
(In reply to Michael Comella (:mcomella) from comment #29)
> Perf tests:

Looks good!
Attachment #8633749 - Attachment is patch: true
Attachment #8633743 - Flags: review?(mhaigh) → review+
Attachment #8633744 - Flags: review?(mhaigh) → review+
Attachment #8633745 - Flags: review?(mhaigh) → review+
Attachment #8633749 - Flags: review?(mhaigh) → review+
url:        https://hg.mozilla.org/integration/fx-team/rev/81fd15f15c6556a6434f70b7ef62899615dcd458
changeset:  81fd15f15c6556a6434f70b7ef62899615dcd458
user:       Michael Comella <michael.l.comella@gmail.com>
date:       Tue Jul 14 14:55:14 2015 -0700
description:
Bug 1147265 - Add filterTouches... to application theme. r=mhaigh

This will affect any activities that do not inherit a theme, which is currently
none of them.

Note that this may affect default inheritance (e.g. we'll no longer inherit
from Holo, if it's the default) but I haven't done the research. To fix it,
you'd have to make the FilteredTouches theme inherit from the default theme
(which could be different for each API level).

url:        https://hg.mozilla.org/integration/fx-team/rev/6cf77a1ea12c560736a702353212b6f2cff6f22a
changeset:  6cf77a1ea12c560736a702353212b6f2cff6f22a
user:       Michael Comella <michael.l.comella@gmail.com>
date:       Tue Jul 14 15:07:12 2015 -0700
description:
Bug 1147265 - Add filterTouches... to sync activities. r=mhaigh

All old sync activities inherit from SyncTheme, which inherits from Gecko on
API < 11 and Gecko.Dialog -> GeckoBaseDialog on v11+.

All fxaccount activities inherit from FxAccountTheme, which inherits from
Gecko.

Note that I don't have an old sync account so I did not test that behavior.

url:        https://hg.mozilla.org/integration/fx-team/rev/689cb91d014dc5dce3dce90680628e28b7741c77
changeset:  689cb91d014dc5dce3dce90680628e28b7741c77
user:       Michael Comella <michael.l.comella@gmail.com>
date:       Tue Jul 14 15:26:48 2015 -0700
description:
Bug 1147265 - Move TabQueueActivity theme to themes.xml. r=mhaigh

url:        https://hg.mozilla.org/integration/fx-team/rev/bb1d0caafe6e8f0e3db0284bf90cbc553c2115a9
changeset:  bb1d0caafe6e8f0e3db0284bf90cbc553c2115a9
user:       Michael Comella <michael.l.comella@gmail.com>
date:       Tue Jul 14 15:27:41 2015 -0700
description:
Bug 1147265 - Add filterTouches... in remaining main FF activities. r=mhaigh

GeckoPreferences inherits from GeckoPreferencesBase which inherits from
GeckoBase, avoiding Gecko, where we put the last filterTouches... so it needs
its own filterTouches... TabQueueActivity is addressed and all other activities
inherit from Gecko.
Comment on attachment 8633743 [details] [diff] [review]
Patch 1 - Add filterTouches... to application theme

This request applies to all patches in this bug.

Approval Request Comment
[Feature/regressing bug #]: None
[User impact if declined]: Users with certain malicious applications installed can open Firefox underneath the app and trick the user into clicking whatever they want.

[Describe test coverage new/current, TreeHerder]: Tested locally.
[Risks and why]: Extremely low - we add an API 9 (the lowest API we support) XML attribute to protect the application. On Views where this doesn't apply, it is ignored so there should be no "casting" style errors. In the worst case, we didn't cover all the views and the error can still occur and I don't see any other negatives.

[String/UUID change made/needed]: None
Attachment #8633743 - Flags: approval-mozilla-beta?
Attachment #8633743 - Flags: approval-mozilla-aurora?
Michael, we don't normally backport sec-moderate bugs without a specific reason. Is there something about this bug that means we should fix it earlier than letting it "ride the trains" to 42?
Flags: needinfo?(michael.l.comella)
(In reply to Al Billings [:abillings] from comment #34)
> Michael, we don't normally backport sec-moderate bugs without a specific
> reason. Is there something about this bug that means we should fix it
> earlier than letting it "ride the trains" to 42?

I was unaware of this policy - wfm.
Flags: needinfo?(michael.l.comella)
Attachment #8633743 - Flags: approval-mozilla-beta?
Attachment #8633743 - Flags: approval-mozilla-aurora?
Flags: needinfo?(abillings)
This bug has caused some regressions: bug 1187547
(In reply to Mark Finkle (:mfinkle) from comment #38)
> This bug has caused some regressions: bug 1187547

That bug says that screen filters, e.g. Twilight (which is like flux for desktop), prevent touches to Firefox from working. In that bug, it's requested for this to be backed out.

To summarize, the compromise is either (if backed out) malicious applications can draw over Firefox and trick the user into performing potentially dangerous actions (e.g. removing a sync account) or (if no change) some applications that draw over Firefox such as screen filters will make Firefox untouchable (and thus unusable), likely making users think Firefox is broken.

Beyond backout/no-backout, I see two potential solutions:
  1) We give the user choice – perhaps by default we disable interactions with obscuring applications and let the user enable it in preferences if they desire. However, few people will find this preference and a lot of people may still think Firefox is broken so imo it's a bad idea
  2) We filter only particular irreversible and damaging interactions – e.g. perhaps we want to prevent accounts from being removed with an obscuring application on top so we only setFilterTouches... on that particular button. We might be able to do some trickery to put a button under these buttons so when the underneath button is clicked, we can send a toast to the user indicating a screen filter is on and they may need to disable it to use this feature. Cons are the layout impact of adding an additional button. I'll research the viability of this.
Flags: sec-bounty? → sec-bounty+
Depends on: 1187547
(In reply to Michael Comella (:mcomella) from comment #39)
> We might be able to do some trickery to put a button under these buttons so
> when the underneath button is clicked, we can send a toast to the user
> indicating a screen filter is on and they may need to disable it to use this
> feature. Cons are the layout impact of adding an additional button. I'll
> research the viability of this.

It turns out the touch events are still captured when the touch event is filtered so this is not viable.

However, the `onFilterTouchEventForSecurity` method [1] is called to determine if a view should be filtered. It's public so we can override it and display a Toast for the relevant Views:

@Override
public void onFilterTouchEventForSecurity(MotionEvent event) {
  final boolean isFiltered = super.onFilterTouchEventForSecurity(event);
  if (isFiltered) {
    Toast.makeText(getContext(), "Screen filter enabled: disable it to use this feature." Toast.LENGTH_LONG).show();
  }
}

I assume this toast would display over the obscuring application - the tap jacking framework uses a toast to obscure so if we display a toast over it, I'd expect it to appear on top.

Alternatively, we can do some additional prompting to the user to ensure this is the action they wanted to take (e.g. have a prompt appear randomly on the screen so it's harder for the malicious application to obscure it). I thought about using the notification bar as an alternative interaction pattern because maybe the system widgets are safe to use but Twilight manages to darken the notification bar too (however, it uses draw over other apps, unlike the tap jacking framework so maybe there's a discrepancy there).

Additional info:
  * Where onFilterTouchEventForSecurity is called [2]
  * MotionEvent.FLAG_WINDOW_IS_OBSCURED [3] - for operating on the received touch event in onFilterTouchEventForSecurity. I don't believe we have the granularity to know if the region that was tapped was obscured since the docs don't mention that possibility.

I feel like most actions the user can take while Firefox is obscured can be malicious so I wonder how futile this is:
* Interacting with web content
  - Opening a malicious link or clicking on malicious content in a page
  - Downloading a malicious file
  - Using intent:// uris to open another malicious app
* Removing sync accounts
* Copy/pasting user data such as passwords (I wonder how feasible this is)
* Clearing private data
* Uninstalling addons/apps, removing downloads

I'd say it's worth trying to protect ourselves as much as possible so we backout this patch and just filter (and display a toast) on removing sync accounts, removing downloads/addons/app, clearing private data, and anything else someone thinks is important.

Margaret, do you have an opinion?

[1]: http://androidxref.com/4.4.4_r1/xref/frameworks/base/core/java/android/view/View.java#7725
[2]: http://androidxref.com/4.4.4_r1/s?refs=onFilterTouchEventForSecurity&project=frameworks
[3]: http://developer.android.com/reference/android/view/MotionEvent.html#FLAG_WINDOW_IS_OBSCURED
Flags: needinfo?(margaret.leibovic)
After talking through this with mcomella, I think we should make a best effort to try to set filterTouchesWhenObscured on actions that can have a big impact on user data, such as clearing history or removing a Firefox account.

However, given that this threat stems from the user having a malicious app installed on their device, there is only so much we can do to protect them, and we still want Firefox to be compatible with valid Android apps, such as Twilight.

In the case where we do block a touch event, I think we should display some sort of notification to explained what just happened, and potentially link to a SUMO article explaining why we block certain actions with these other apps enabled.
Flags: needinfo?(margaret.leibovic)
(In reply to :Margaret Leibovic from comment #41)
> After talking through this with mcomella, I think we should make a best
> effort to try to set filterTouchesWhenObscured on actions that can have a
> big impact on user data, such as clearing history or removing a Firefox
> account.

Notably, I don't see any way of protecting the web content area.
First, I think we should back this code out.

I'd be interested to see what other apps, like Facebook, Twitter and Chrome do with regards to tap jacking. Doing a case by case approach means that we'll need to keep adding protection to "risky" actions forever. Which means we'll forget and the app will evolve into a mish-mash of tap protection.

I think the case by case approach is not sustainable, and we should consider just not adding any tap jacking protection.
(In reply to Mark Finkle (:mfinkle) from comment #43)
> I'd be interested to see what other apps, like Facebook, Twitter and Chrome
> do with regards to tap jacking.

If I did this search correctly, Chrome doesn't seem to protect against tab jacking:
 https://code.google.com/p/chromium/codesearch#search/&q=filterTouches&sq=package:chromium&type=cs

> Doing a case by case approach means that
> we'll need to keep adding protection to "risky" actions forever. Which means
> we'll forget and the app will evolve into a mish-mash of tap protection.

A mish-mash approach may not be sustainable (or perfect) but it could still be better than nothing. I think the biggest concern is, "Can we filter touches in a way that users will understand?"
url:        https://hg.mozilla.org/integration/fx-team/rev/4989e289b61ede8eace73907f1680a31aa6b5104
changeset:  4989e289b61ede8eace73907f1680a31aa6b5104
user:       Michael Comella <michael.l.comella@gmail.com>
date:       Wed Aug 05 17:05:06 2015 -0700
description:
Bug 1147265 - Backout changeset bb1d0caafe6e.

url:        https://hg.mozilla.org/integration/fx-team/rev/736f436c2523329c57c25e0eb61314cf7e1d6620
changeset:  736f436c2523329c57c25e0eb61314cf7e1d6620
user:       Michael Comella <michael.l.comella@gmail.com>
date:       Wed Aug 05 17:05:30 2015 -0700
description:
Bug 1147265 - Backout changeset 689cb91d014d.

url:        https://hg.mozilla.org/integration/fx-team/rev/20b782a2f08d45401d782ab0b59daafb84d1abce
changeset:  20b782a2f08d45401d782ab0b59daafb84d1abce
user:       Michael Comella <michael.l.comella@gmail.com>
date:       Wed Aug 05 17:06:10 2015 -0700
description:
Bug 1147265 - Backout changeset 6cf77a1ea12c.

url:        https://hg.mozilla.org/integration/fx-team/rev/1c2dfa848d83c5b9521a9fcd3493718dd11ba187
changeset:  1c2dfa848d83c5b9521a9fcd3493718dd11ba187
user:       Michael Comella <michael.l.comella@gmail.com>
date:       Wed Aug 05 17:06:35 2015 -0700
description:
Bug 1147265 - Backout changeset 81fd15f15c65.
Reopen while we decide on the proper approach.

Note that while in an ideal world, I prefer if we do partial protection, it might be worthwhile to consider where else our development efforts could be placed and if it's actually worth the development effort to implement partial protection.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: Firefox 42 → ---
(In reply to Michael Comella (:mcomella) from comment #46)
> Reopen while we decide on the proper approach.
> 
> Note that while in an ideal world, I prefer if we do partial protection, it
> might be worthwhile to consider where else our development efforts could be
> placed and if it's actually worth the development effort to implement
> partial protection.

Yeah, the challenge here is deciding what is worth protecting. I agree with mfinkle that this case by case approach is not very robust, so I would only want to see this protection for actions that can have a very large impact on user data.

If we were to implement this protection on individual controls, I could see us doing it on the "clear history" button in the history panel and the "clear private data" setting in settings. Perhaps also removing a Firefox account.

However, in these cases, the impact is data loss, not data being compromised to a third party, so I don't see this as a high priority threat.
Given comment 43 and comment 47, I don't think it's worth prioritizing this over other things - unassigning. We can revisit this if we gain some free cycles or it becomes a bigger issue.
Assignee: michael.l.comella → nobody
Duplicate of this bug: 1199633
Group: core-security → firefox-core-security
This is a public issue that has gotten multiple reports, we might as well unhide this.
Group: firefox-core-security
Mike, what do you think we should do about this bug? At this point, I feel like we should just decide to WONTFIX it.

As has been said in previous comments, an attack here depends on having a separate malicious app installed, and attempts to prevent this attack can interfere with the UX of non-malicious apps.
Flags: needinfo?(michael.l.comella)
(In reply to :Margaret Leibovic from comment #51)
> Mike, what do you think we should do about this bug? At this point, I feel
> like we should just decide to WONTFIX it.

I stand by comment 46 – I don't think it's worth the development time. I also agree with the sentiments that 1) it negatively affects the users of non-malicious apps (e.g. Twilight), 2) the user has to already have installed a malicious app (so we're not the only ones who can be affected), and 3) we're likely to forget to add protection in crucial places so it's generally a losing battle.

These issue put together, I agree with WONTFIX.
Status: REOPENED → RESOLVED
Closed: 4 years ago4 years ago
Flags: needinfo?(michael.l.comella)
Resolution: --- → WONTFIX
there's simple way to Fix this issue.

Use EXPORTED=FALSE attribute for all ACTIVITY in androidmanifest.xml file.
(In reply to Pintu from comment #53)
> there's simple way to Fix this issue.
> 
> Use EXPORTED=FALSE attribute for all ACTIVITY in androidmanifest.xml file.

This approach does make the attack vector more complicated (thank you for pointing it out), however, the malicious app can launch the main activity (which is `exported=true`) and create an attack through there. In the worst case, the malicious app can go through the launcher too.
Duplicate of this bug: 1561419
You need to log in before you can comment on or make changes to this bug.