1220519 - (CVE-2016-1932) Web Notification Origin Spoof and FullScreen Display DOS

Status: RESOLVED DUPLICATE of bug 1213421

(Toolkit Graveyard :: Notifications and Alerts, defect)

Description

[xisigr]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.80 Safari/537.36

Steps to reproduce:

User Agent:Mozilla/5.0 (Windows NT 6.1; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0

User Agent:Mozilla/5.0 (Windows NT 10.0; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0  

（1）Origin Spoof Demo：http://xisigr.com/test/notification/1.html

（2）FullScreen Display DOS Demo：http://xisigr.com/test/notification/2.html


Actual results:

(1) In the notification dialog, no originates hints and warnings.The attacker can then display a malicious notification dialog to the user that seemingly originates from the trusted site. Typically this notification dialog would mimic the legitimate site. An attacker may exploit this vulnerability to spoof an interface of a trusted web site.

(2) Web Notification will be fully displayed, resulting in full screen display notification dialog to denial of service attack.



Expected results:

（1）Web Notification Origin Spoof 
（2）FullScreen Display DOS


CREDIT
--------------------
This vulnerability was discovered by xisigr of Tencent's Xuanwu LAB(http://www.tencent.com).
Email:[e-mail]

Comment 1

[:Gijs (he/him)]

The first is already addressed on Nightly (45). It seems the second isn't, on Windows 8 or below (not sure if we do native notifications on win10 yet).

It seems to me like the impact is very low either way, because (a) you need permission from the user in order to show notifications, which does display your site address, (b) you're only spoofing the notification, which doesn't actually let you steal credentials or deceive the user in some other way - the worst you could do is make the user go back to the page where they allow notifications.

Seems to me like this is sec-low at best and can be unhidden.

On the whole, I also wonder if notifications should be automatically closed when the originating window unloads.

Comment 2

[Matthew N. [:MattN]]

Yes, #1 was fixed by bug 1202933.

#2 is going to be fixed for XUL notifications by bug 1213421 in the next few weeks on Nightly. (It's in our prioritized backlog).

(In reply to :Gijs Kruitbosch from comment #1)
> The first is already addressed on Nightly (45). It seems the second isn't,
> on Windows 8 or below (not sure if we do native notifications on win10 yet).

We don't do native on Windows yet so all Windows uses XUL, same with old OS X and linux without libnotify.

> It seems to me like the impact is very low either way, because (a) you need
> permission from the user in order to show notifications, which does display
> your site address, (b) you're only spoofing the notification, which doesn't
> actually let you steal credentials or deceive the user in some other way -
> the worst you could do is make the user go back to the page where they allow
> notifications.

Well, that page can do a window.open to any other origin and preventDefault from the click so it can be any origin that opens.

> Seems to me like this is sec-low at best and can be unhidden.

Yeah, probably.

> On the whole, I also wonder if notifications should be automatically closed
> when the originating window unloads.

I believe that's what the spec specifies for notifications created outside a service worker but we may suggest a spec change to allow re-opening the origin upon click if the page is closed (since the click handler would be dead).

Comment 3

[Matthew N. [:MattN]]

From Fx44 (via bug 1209602) we also have an option directly in the notification to disable notifications from the originating origin which can help with the DOS (once we truncate the text to ensure it's visible on screen).

Comment 4

[:Gijs (he/him)]

(In reply to Matthew N. [:MattN] from comment #2)
> > It seems to me like the impact is very low either way, because (a) you need
> > permission from the user in order to show notifications, which does display
> > your site address, (b) you're only spoofing the notification, which doesn't
> > actually let you steal credentials or deceive the user in some other way -
> > the worst you could do is make the user go back to the page where they allow
> > notifications.
> 
> Well, that page can do a window.open to any other origin and preventDefault
> from the click so it can be any origin that opens.

Sure, I just don't really see what the advantage would be over just opening <some other page> with window.open. You still need to spoof something in the main window to get the user to give you credentials or other private information, so you may as well not bother with the notification.

Comment 5

[Matthew N. [:MattN]]

I'm just going to dupe to bug 1213421 as it covers the remaining issue.