1147265 - Tap Jacking attack on android mozilla browser

Status: RESOLVED WONTFIX

(Firefox for Android Graveyard :: General, defect)

Description

[kaleemshaik786]

Attachment: mozilla tap jacking.zip

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"/>

Comment 1

[Daniel Veditz [:dveditz]]

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?

Comment 2

[Kevin Brosnan [Ex-Mozilla]]

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.

Comment 4

[kaleemshaik786]

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..

Comment 5

[kaleemshaik786]

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.

Comment 6

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

(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

Comment 7

[kaleemshaik786]

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)

Comment 8

[kaleemshaik786]

Hi,

Please provide me an update on this..

Thanks,
kaleem

Comment 9

[kaleemshaik786]

Hi,

Please let me know any progress on this..


Thanks,
Kaleem

Comment 10

[Al Billings [:abillings - ex-MoCo]]

(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.

Comment 11

[Al Billings [:abillings - ex-MoCo]]

Can you assign this security bug to a dev to work on?

Comment 12

[Mark Finkle (:mfinkle) (use needinfo?)]

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.

Comment 13

[Mark Finkle (:mfinkle) (use needinfo?)]

Mike

Some examples of how other apps used this:
https://github.com/PersoApp/import/commit/d29c2eafcabbf1b0e2f38f7fa4039969e74640ff

Also, we might need to add it to the "positive" action button for custom dialogs:
https://github.com/Skipper28/android_frameworks_base/blob/4ea1222cc6a63d6c5b621cf82851fd6eeb66bcbe/packages/VpnDialogs/src/com/android/vpndialogs/ConfirmDialog.java#L81

Comment 14

[kaleemshaik786]

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
        }
    }
}

Comment 15

[kaleemshaik786]

Dear Mike,

Kindly Provide update on this 

Best,
Kaleem

Comment 16

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

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! :)

Comment 17

[kaleemshaik786]

Hi Mike,

Thank you so much for the update.. Will wait for next week :)

Comment 18

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

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.

Comment 19

[kaleemshaik786]

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

Comment 20

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

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.

Comment 21

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Attachment: Patch 1 - Add filterTouches... to application theme

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).

Comment 22

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Attachment: Patch 2 - Add filterTouches... to sync activities

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.

Comment 23

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Attachment: Patch 3 - Move TabQueueActivity theme to themes.xml

Comment 24

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Attachment: Patch 4 - Add filterTouches... in main FF activities

Comment 25

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Attachment: Patch 4 - Add filterTouches... in remaining main FF activities.

Comment 26

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

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.

Comment 27

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

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.

Comment 28

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=17e234d1c78c

Comment 29

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Perf tests:
 Baseline: https://treeherder.mozilla.org/#/jobs?repo=try&revision=955f35df509b&exclusion_profile=false
 w/ changes (comment 28): https://treeherder.mozilla.org/#/jobs?repo=try&revision=f912c0a0d70f&exclusion_profile=false

Comment 30

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

(In reply to Michael Comella (:mcomella) from comment #29)
> Perf tests:

Looks good!

Comment 31

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

url:        https://hg.mozilla.org/integration/fx-team/rev/81fd15f15c6556a6434f70b7ef62899615dcd458
changeset:  81fd15f15c6556a6434f70b7ef62899615dcd458
user:       Michael Comella <[e-mail]>
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 <[e-mail]>
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 <[e-mail]>
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 <[e-mail]>
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 32

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

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

Comment 33

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/81fd15f15c65
https://hg.mozilla.org/mozilla-central/rev/6cf77a1ea12c
https://hg.mozilla.org/mozilla-central/rev/689cb91d014d
https://hg.mozilla.org/mozilla-central/rev/bb1d0caafe6e

Comment 34

[Al Billings [:abillings - ex-MoCo]]

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?

Comment 35

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

(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.

Comment 36

[kaleemshaik786]

Hi al, 
I hope this is eligible for bounty. Kindly update me on this

Comment 37

[Al Billings [:abillings - ex-MoCo]]

(In reply to kaleemshaik786 from comment #36)
> I hope this is eligible for bounty. Kindly update me on this

In the future, please follow the bug bounty program instructions at https://www.mozilla.org/en-US/security/client-bug-bounty/ and email [e-mail] with bounty requests and for information. This allows us to not clog up bugs with issues not related to fixing the issue.

This was marked for bounty eligibility on March 25. We review bounty requests once a bug is fixed (or has an understood patch). I expect it will be reviewed at our next committee meeting.

Comment 38

[Mark Finkle (:mfinkle) (use needinfo?)]

This bug has caused some regressions: bug 1187547

Comment 39

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

(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.

Comment 40

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

(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

Comment 41

[: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.

Comment 42

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

(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.

Comment 43

[Mark Finkle (:mfinkle) (use needinfo?)]

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.

Comment 44

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

(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?"

Comment 45

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

url:        https://hg.mozilla.org/integration/fx-team/rev/4989e289b61ede8eace73907f1680a31aa6b5104
changeset:  4989e289b61ede8eace73907f1680a31aa6b5104
user:       Michael Comella <[e-mail]>
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 <[e-mail]>
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 <[e-mail]>
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 <[e-mail]>
date:       Wed Aug 05 17:06:35 2015 -0700
description:
Bug 1147265 - Backout changeset 81fd15f15c65.

Comment 46

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

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.

Comment 47

[:Margaret Leibovic]

(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.

Comment 48

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

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.

Comment 50

[Daniel Veditz [:dveditz]]

This is a public issue that has gotten multiple reports, we might as well unhide this.

Comment 51

[:Margaret Leibovic]

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.

Comment 52

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

(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.

Comment 53

[Paresh]

there's simple way to Fix this issue.

Use EXPORTED=FALSE attribute for all ACTIVITY in androidmanifest.xml file.

Comment 54

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

(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.