1222798 - (CVE-2017-5394) Firefox 43 for Android : Clickjacking / CSRF attacks and Location Bar Spoofing (URL and SSL Spoofing)

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Jordi Chancel]

Attachment: Screenshot of the vulnerability.png

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

Steps to reproduce:

With Firefox 42 for Android , it's possible to make Clickjacking /CSRF attacks and possible URL and SSL Spoofing.

Step1 : go to https://www.alternativ-testing.fr/Research/Mozilla/android/android-Firefox42.0-Clickjacking-CSRF-URL-and-SSL%20Spoofing/testfs.html and click on the step1 link.

Step2 : click on the step2 Link. 

step3 : an alert() JavaScript Function will be used for redirect the user on the tab opened by the first link (step1 link) and the location bar will appears like a secure webpage and show "https://mobile.twitter.com/session/new" but the visible content of the webpage is the content of "https://www.alternativ-testing.fr/Research/Mozilla/android/android-Firefox42.0-Clickjacking-CSRF-URL-and-SSL%20Spoofing/testfs.html" if your login and password for mobile.twitter.com is registred , by clicking on the button "ClickJack-twitter-login" you will be connected on your twitter account ( i will uploaded you a video and a screenshot for show you what this vulnerability is exactly)




Actual results:

An attacker can use this vulnerability for make clickjacking /CSRF attacks and possibly URL ans SSL Spoofing.


Expected results:

The visible content of the webpage is wrong and the real content of the URL showed is invisible and this can lead to ClickJacking and Cross-Site Request Forgery and also possible URL ans SSL Spoofing.

Comment 1

[Jordi Chancel]

(The testcase has been tested on a Samsung Galaxy S5 4g+ and works very well)

In fact, the visible content is the content of the attacker webpage (eg: attacker.com) , but the real content is the content of the URL showed in the Location Bar (eg: bank.com) , its content is invisible but can be clicked , so this vulnerability can be used for multiple reason: ClickJacking attacks / CSRF attacks and I think it's possible to use this vulnerability for spoofed the URL and SSL into the location bar leading to a Location Bar Spoofing vulnerability, with the URL and the SSL indicator spoofed.

I will make a video for demonstrate you the dangerosity of this vulnerability soon (for an attack of ClickJacking / CSRF ).

Comment 2

[Jordi Chancel]

The testcase works also very well on Firefox Beta 43.0b1 and Firefox Nightly 45.0a1

Comment 3

[Jordi Chancel]

Attachment: Video-Example n°1 - Firefox 42 for Android - ClickJacking/CSRF attack.html

Desmonstration of a ClickJacking / CSRF vulnerability. ( I use a Samsung Galaxy S5 4G+ Android Lollipop 5.0.2 )

Comment 4

[Daniel Veditz [:dveditz]]

Confirming (in Beta). The test loads twitter in an background tab which ends up drawing the twitter URL bar on top of the attacker's fullscreen page. Also uses alerts to steal focus back to the intended tab, which we're getting rid of on desktop because it's used for spoofing like pop-unders. I guess I should check on Nightly because that feature may have come to Fennec (different front end so maybe not).

Comment 5

[Daniel Veditz [:dveditz]]

Attachment: testcase

Saving the testcase in case it goes away.

Comment 6

[Daniel Veditz [:dveditz]]

The result is a pretty convincing spoof because the URL bar is real and functional, although if you go to the tab chooser and back then you get the real content. Can't quite rate it "high" because of the clunkiness of multiple clicks and waiting for things to load (will raise suspicions).

Comment 7

[Jordi Chancel]

if  i code a testcase which require only to click on only one link , this bug can be defined high? 
(the alert() JS function will be again used but i think that i can code a testcase wich require to click on only one link )

Comment 8

[Jordi Chancel]

For Daniel Veditz: look comment 7 before to read this comment.

Like you can view in this video ( https://bugzilla.mozilla.org/attachment.cgi?id=8684962 ) into the attachments in this bug report, 

This vulnerability can be used also for ClickJacking/CSRF attacks and I think that we can execute a XPI addon silently by a simple click on a button which is placed at the same place where the button of confirmation allowing the execution of this addon is also placed ( this attack is remotely possible ).

And like I already said in the comment 7 where i sent a "needinfo flag" to Daniel Veditz {[e-mail]} , I think that the actual testcase can be reduced.

Explaination : I think than it's possible to code a testcase wich require to click on only one link ( excepted the clicks on the alert() JavaScript functions which are needed for the actual exploitation).

But it is probable that we can reduce or use others functions than alert() for crafted a testcase which require a click on only one link , which also allowing to define this vulnerability like sg:high .

Comment 9

[Jordi Chancel]

(In reply to Jordi Chancel from comment #8)

> (...) 
> I think that we can execute a XPI addon silently by a simple click on a button
> which is placed at the same place where the button of confirmation allowing
> the execution of this addon is also placed ( this attack is remotely
> possible ).
> 
> (...)

I've makes some tests for try to execute silently a XPI addon but i haven't found a way for do this.

Comment 10

[Jordi Chancel]

This vulnerability works on all Firefox versions : 
Firefox 44.0.2 (stable) , Firefox 45.0b9 (Beta) , Firefox 47.0a1 (Nightly) ...

Al, could you assign someone to code a patch for this vulnerability please?

In the last similar vulnerability ( Bug 1149000 ) , Kartikaya Gupta ( [e-mail] or [e-mail] ) has been assigned and i think he could be again assigned for this new report.

Thanks.

Comment 11

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

I can't assign developers to work on issues, Jordi. I can cc Katikaya to ask but that's it.

Comment 12

[Kartikaya Gupta (email:[e-mail])]

Unfortunately at the moment I don't have a lot of time to dig into this. Do you know what we would need to fix in the browser to stop this vulnerability? Is it that the alert dialog can cause switching to another tab while remaining in fullscreen?

Comment 13

[Jordi Chancel]

(Sorry for the first needinfo without comment , it's an error of manipulation)

This vulnerability works again on all Firefox versions : 
Firefox 45.0.1 (stable) , Firefox 46.0b4 (Beta) , Firefox 48.0a1 (Nightly) ...

I hope that this vulnerability allowing spoofing of URL and SSL, and also allowing clickjacking attacks and again others malicious results will be corrected quickly and that it does not happen the same problem that in Bug1158439 (which have been defined obsolete after several updates due to multiple change of parameters essential to exploit this vulnerability).

So it is important to fix this vulnerability before that an update make it impossible to reproduce the proof of concept of this  security bug report.


I've needinfo some Mozilla people which have also previously fixed some vulnerabilities in Firefox for Android.

Someone of you that i "needinfo?" can try to fix this vulnerability please?

Thanks

Comment 14

[:Margaret Leibovic]

(In reply to Jordi Chancel from comment #13)
> (Sorry for the first needinfo without comment , it's an error of
> manipulation)
> 
> This vulnerability works again on all Firefox versions : 
> Firefox 45.0.1 (stable) , Firefox 46.0b4 (Beta) , Firefox 48.0a1 (Nightly)
> ...
> 
> I hope that this vulnerability allowing spoofing of URL and SSL, and also
> allowing clickjacking attacks and again others malicious results will be
> corrected quickly and that it does not happen the same problem that in
> Bug1158439 (which have been defined obsolete after several updates due to
> multiple change of parameters essential to exploit this vulnerability).
> 
> So it is important to fix this vulnerability before that an update make it
> impossible to reproduce the proof of concept of this  security bug report.

What will change in a update that makes it impossible to reproduce this security issue? A change in Twitter's website? Ideally we should create a reduced testcase that doesn't depend on an external website.

Can you answer kats's question from comment 12? What is your recommended fix here?

Since this is related to urlbar security, let's see if sebastian is interested in taking a look at this.

Comment 15

[Jordi Chancel]

(In reply to :Margaret Leibovic from comment #14)
> (In reply to Jordi Chancel from comment #13)
> > (Sorry for the first needinfo without comment , it's an error of
> > manipulation)
> > 
> 
> What will change in a update that makes it impossible to reproduce this
> security issue? A change in Twitter's website? Ideally we should create a
> reduced testcase that doesn't depend on an external website.
> 
> Can you answer kats's question from comment 12? What is your recommended fix
> here?
> 
> Since this is related to urlbar security, let's see if sebastian is
> interested in taking a look at this.

For example: Bug884488 and Bug1158439 haven't been fixed but after several update, thses vulnerabilities have been defined obsolete even if these update haven't a fix for these Bug.

Comment 16

[Jordi Chancel]

The testcase works with onclick and ontouchstart on all Firefox version but on Nightly it works only with ontouchstart event ( a cursor can't be used ) 

I Needinfo? me and when i've found a perfect testcase which works with onclick event on Nightly, I will delete this Needinfo? flag.

Comment 17

[Jordi Chancel]

Attachment: testcase for Nightly 48.0a1

On Nightly 48.0a1 for Android , 
if you use a mouse connected to the android device, the testcase must use the onclick event because this Firefox Nightly version don't use the ontouchstart if you click with a cusor.
So in the Nightly 48.0a1 for android you must use onclick event and ontouchstart event (onclick event if a cursor is used and ontouchstart event if you touch the screen).

Comment 18

[Jordi Chancel]

Comment on attachment 8686183 [details]
testcase

This testcase works perfectly on: 
1) Firefox 45.0.1 (stable version) 
2) Firefox 46.0b(*) (Beta version).

But on Firefox 48.0a(*) (Nightly vserion) you must use the last testcase uploaded for Nightly if you use a cursor on your Android device.

Comment 19

[Sebastian Kaspari (:sebastian; :pocmo)]

I'll have a look.

Comment 20

[Jordi Chancel]

Sebastian, could you look in priority this vulnerability before the Bug1227538 plase? 

It's because the severity and the impact of this vulnerability are more important than Bug1227538. and you was assigned on it before Bug1227538.

Thanks.

Comment 21

[Sebastian Kaspari (:sebastian; :pocmo)]

@snorp: Does someone from the platform team have time to look into this? It seems like the frontend / browser chrome is behaving correctly but we end up in a situation where the "attacker's site" overlays another website (Great for Clickjacking).

What I see from debugging this:

* (Tab 1) We load the demo site and update the chrome accordingly

* The first link opens a new tab (Tab 2) (target="_blank") and injects some html+js with a 10 second timeout to load twitter and show an alert. We automatically switch to the new tab.
* (Tab 1) Additionally the first link (via ontouchstart) starts a 1 second timeout that shows an alert. This alert, after 1 second, leads to us automatically selecting tab 1 again. [1]

* (Tab 1) The second link sets the tab to fullscreen mode.

* (Tab 2) The 10 second timeout will fire, show an alert, we automatically select tab 2 again [1], leave the fullscreen mode [2], and will load Twitter.

* We end up on tab 2 (Twitter) but still see the content of tab 1. Clicks on the content will click elements on Twitter's page. The chrome however correctly shows that we are on Twitter and the tabs tray has the correct selections and even shows a Twitter thumbnail.

Note: For this to "work" you have to have the right timing and click "link 2" before the 10 second timeout in tab 2 fires. If you just wait 10 seconds after clicking link 1 then we switch to tab 2 (because of the alert) and just load twitter normally. Going to fullscreen mode first is important for this bug. We actually have code in place to exit fullscreen mode when switching tabs [2] but this doesn't seem to help here.

[1] https://dxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/browser.js#4206-4207
[2] https://dxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/browser.js#1278

Comment 22

[Sebastian Kaspari (:sebastian; :pocmo)]

Renominating: See comment above.

Comment 23

[James Willcox (:snorp) ([e-mail]) (he/him)]

OK, Eugen can you look at this next week?

Comment 24

[Eugen Sawin [:esawin]]

Attachment: 0001-Bug-1222798-1.1-Finish-DOM-fullscreen-change-immedia.patch

I think this exploit has been introduced with bug 1161802, which enables support for fullscreen transitions/fading.

This patch fixes the issue by finishing the DOM fullscreen change without delay.

I don't know whether this breaks fullscreen transitions or not, do we have tests for this?

Comment 25

[Xidorn Quan [:xidorn] UTC+11]

Comment on attachment 8770664 [details] [diff] [review]
0001-Bug-1222798-1.1-Finish-DOM-fullscreen-change-immedia.patch

Review of attachment 8770664 [details] [diff] [review]:
-----------------------------------------------------------------

Unconditionally doing this would certainly break the fullscreen transition. It would make the document change at the beginning of the transition.

Could you explain why the content of Tab 1 (the testcase page) is displayed over Tab 2 (the mobile twitter) if FinishDOMFullscreenChange is called asynchronously?

Comment 26

[Eugen Sawin [:esawin]]

From what I can see, we fail because we set focus (nsFocusManager::SetFocus) before finishing the fullscreen change.

By finishing the DOM fullscreen change in sync, we make sure the fullscreen state is cleared first, before updating the focus. Otherwise, all Android-specific tab/content handling looks identical between the sync and async cases.

It's not clear to me, why preserving this sequence is important or how the focusing mechanics are supposed to work on Android with fullscreen transitions.

Comment 27

[Daniel Veditz [:dveditz]]

(In reply to Jordi Chancel from comment #7)
> if  i code a testcase which require only to click on only one link , this
> bug can be defined high? 

Apparently you cleared the needinfo immediately after setting it; sorry I didn't see this question. If you can reduce the testcase to something that could plausibly fool a user then we could raise the severity. I'm not optimistic that you can obscure the full-screen warning and prompt enough to make a user think everything is just fine and normal.
 
> This vulnerability can be used also for ClickJacking/CSRF attacks and I
> think that we can execute a XPI addon silently by a simple click on a button
> which is placed at the same place where the button of confirmation allowing
> the execution of this addon is also placed ( this attack is remotely
> possible ).

That would be a different PoC and possibly require an additional fix; please file as a separate bug.

Comment 28

[Xidorn Quan [:xidorn] UTC+11]

(In reply to Eugen Sawin [:esawin] from comment #26)
> From what I can see, we fail because we set focus (nsFocusManager::SetFocus)
> before finishing the fullscreen change.
> 
> By finishing the DOM fullscreen change in sync, we make sure the fullscreen
> state is cleared first, before updating the focus. Otherwise, all
> Android-specific tab/content handling looks identical between the sync and
> async cases.
> 
> It's not clear to me, why preserving this sequence is important or how the
> focusing mechanics are supposed to work on Android with fullscreen
> transitions.

I think we need to understand the details why this could happen. Does setting focus do anything about what would be displayed?

What FinishDOMFullscreenChange does when exiting fullscreen is basically just resetting the document state and queuing a fullscreenchange event to be dispatched in the next tick.

Having said that, probably it is because the refresh driver is unexpectedly activated by the queued event somehow? Could that be the case?

Comment 29

[Eugen Sawin [:esawin]]

Attachment: 0001-Bug-1222798-1.2-Update-tab-selection-after-fullscree.patch

The behavior change (between the sync and async fullscreen change) in the focusing mechanics was triggered by changed frame visibility [1].

Reading the "sizemodechange" event handling on B2G, I think we need to adjust content visibility once the fullscreen transition has ended, but there is no such mechanic on Android afaik.

The way this is handled on Android is through the "Tab:Selected" event chain. We need to defer handling this event to the "fullscreenchange" handler, to make sure that the fullscreen transition has concluded.

[1] https://dxr.mozilla.org/mozilla-central/source/docshell/base/nsDocShell.cpp#6079

Comment 30

[Sebastian Kaspari (:sebastian; :pocmo)]

Comment on attachment 8774441 [details] [diff] [review]
0001-Bug-1222798-1.2-Update-tab-selection-after-fullscree.patch

Review of attachment 8774441 [details] [diff] [review]:
-----------------------------------------------------------------

Looks reasonable. I'll flag xidorn for review too.

Comment 31

[Xidorn Quan [:xidorn] UTC+11]

Comment on attachment 8774441 [details] [diff] [review]
0001-Bug-1222798-1.2-Update-tab-selection-after-fullscree.patch

Review of attachment 8774441 [details] [diff] [review]:
-----------------------------------------------------------------

I'm not familiar with the chrome js code on Android, but the logic looks reasonable.

I would consider this as a hacking fix. I think it would still be better to understand what really happens underneath, why the rendering could be out of sync with all other things.

Comment 32

[Eugen Sawin [:esawin]]

Sorry for the delay, but I didn't get the last review bugmail for some reason.

Comment 33

[Eugen Sawin [:esawin]]

Try looks OK
https://treeherder.mozilla.org/#/jobs?repo=try&revision=bed788d6d32d
https://treeherder.mozilla.org/#/jobs?repo=try&revision=3a2858e003f1

Comment 34

[Eugen Sawin [:esawin]]

Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=bc6da879483e2c91707b2f7312ece04b876972c6

Lots of jemalloc crashes, but don't seem related to this.

Comment 35

[Eugen Sawin [:esawin]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/9d953e2b4ab5

Comment 36

[Eugen Sawin [:esawin]]

https://hg.mozilla.org/mozilla-central/rev/9d953e2b4ab5

Comment 37

[Matt Wobensmith [:mwobensmith][:matt:]]

Jordi, please verify that this has been fixed. Thank you.

Comment 38

[Jordi Chancel]

This vulnerability is fixed on Firefox Beta 51 for Android.