External Protocol / scheme handler dialog can be spawned from background tabs leading to spoofing of the origin of the link that's opening
Categories
(Firefox :: Security, defect, P3)
Tracking
()
People
(Reporter: lijoparappur, Assigned: emz)
References
Details
(Keywords: csectype-spoof, reporter-external, sec-low, Whiteboard: [fixed by Bug 1661030][post-critsmash-triage][adv-main82+])
Attachments
(2 files)
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:76.0) Gecko/20100101 Firefox/76.0
Steps to reproduce:
Please visit the link https://sites.google.com/view/lijocheck/home
there have two button one have set time out 40, another set timeout 4000
if click button 40 s launch application will popup on about:blank it will not load contact form of apple
if click button 4000 s launch application will popup on https://www.apple.com/contact/ and user think its from https://www.apple.com/contact/ will contact them with given number
Actual results:
launch application window opened in spoof url it must open on about blank url.
Expected results:
launch application window must open on about blank url.
html
<html>
<head>
<title>Tel Check</title>
</head>
<body>
<li>click button 40 s <button onclick="pwn40()">clickme</button> </li>
<li>click button 4000 s <button onclick="pwn4000()">clickme</button> </li>
<br>
<script>
var pwn40 = () => {
win = window.open("https://www.apple.com/contact/ ", "test", "width=800 height=800");
setTimeout("win.location = 'tel:tel:+919747 '", 40);
}
var pwn4000 = () => {
win = window.open("https://www.apple.com/contact/ ", "test", "width=400 height=400");
setTimeout("win.location = 'tel:+919747 '", 400);
}
</script>
</body>
</html>
Serve it on a wb server
|
||
Comment 1•5 years ago
|
||
This is basically https://bugs.chromium.org/p/chromium/issues/detail?id=1005596 .
(In reply to Daniel Veditz [:dveditz] from bug 1635474 comment #6)
Similar, but in this case there are two tabs involved and the background one can legitimately run script at any time. We could in theory focus the tab that triggered the dialog (rude?), or suppress the dialog/navigation if it's coming from a window that isn't active (like a popup blocker?), or try to state the origin of the initiating window on the prompt. That last is pretty weak and we've seen people not really notice the "wrong origin" case on the HTTP Auth dialog.
We just need to switch to permissions for this, and get rid of this ancient dialog. I started work on bug 1196151 before this was reported, which cleans things up a bit (the implementation is a bit messy atm), and then I hope to be able to switch away from the dialog in e.g. bug 1565574.
It appears Chrome has just changed whatever dialog they show to include the origin requesting the link. I think the remaining question for us is what we want to do in the cases where we don't show a dialog at all - mailto: on desktop (which I think is fine, as no email client will actually send an email), but I'm unclear on which other things exist on Fenix, and what we do there.
I think bug 1635474 is effectively the same but for iOS, so I'm moving discussion here given that this is desktop-focused. Dan, thoughts?
|
||
Updated•5 years ago
|
|
||
Comment 2•5 years ago
|
||
How do permissions help? Because the victim would presumably not have given tel: permission to the attacker, and then would have to switch back to that tab to interact with the doorhanger? Once the user grants permission (if it's remembered) then that particular scheme-origin pair would move into the no-dialog case like mailto:. That's probably fine? Users can do that today, and if they choose badly then every site can abuse the scheme. With a permission model only the site the user trusted could abuse it.
How far out is that work? Is it worth doing a short-term band-aide of stuffing the true origin in that dialog in the meanwhile? It's really not that effective a fix though, as we've noted somewhere in one if these bugs. It's a CYA move for us, but probably not much help in an actual spoofing attack.
|
|
||
Comment 3•5 years ago
|
||
(In reply to Daniel Veditz [:dveditz] from comment #2)
How do permissions help? Because the victim would presumably not have given
tel:permission to the attacker, and then would have to switch back to that tab to interact with the doorhanger?
Yes, the doorhanger would not show unless the tab was selected, I assume.
Once the user grants permission (if it's remembered) then that particular scheme-origin pair would move into the no-dialog case like
mailto:. That's probably fine? Users can do that today, and if they choose badly then every site can abuse the scheme. With a permission model only the site the user trusted could abuse it.
Yep.
How far out is that work?
I'm not sure. I started some groundwork but I won't know how easy it is to switch to permissions until I actually try to do it.
Is it worth doing a short-term band-aide of stuffing the true origin in that dialog in the meanwhile? It's really not that effective a fix though, as we've noted somewhere in one if these bugs. It's a CYA move for us, but probably not much help in an actual spoofing attack.
I don't think it's worth it. If anything I'd sooner check if the originating browsingcontext is in an active docshell and just ignore the navigation if it isn't... That fixes this bug but not all the other things that would be fixed by switching to permissions.
This bug is part of a group of bugs in a security or private group which have the old default Severity of normal which has not been changed, and the default priority of --. This indicates that this bugs Severity should be set to -- so it will show up in triage lists.
Trying to set that severity again.
|
||
Comment 7•5 years ago
|
||
The severity field is not set for this bug.
:johannh, could you have a look please?
For more information, please visit auto_nag documentation.
|
|
||
Updated•5 years ago
|
|
||
Updated•5 years ago
|
|
Reporter | |
Comment 8•5 years ago
|
||
Hi,
Any Updates about issue and reward
|
Assignee | |
Updated•4 years ago
|
|
|
Reporter | |
Comment 9•4 years ago
|
||
Hi
Anything about reward
|
|
||
Comment 10•4 years ago
|
||
(In reply to lijoparappur from comment #9)
Anything about reward
Unfortunately this bug does not qualify for our bounty program due to its low severity. Is this example PoC hosted on a web site somewhere? We've gotten bugs about abusing tel: on apple.com support for years.
|
||
Updated•4 years ago
|
|
||
Updated•4 years ago
|
|
||
Comment 11•4 years ago
|
||
Hi Gijh,
Can you explain a bit how the fix from Bug 1661030 should work in this case?
Right now on the latest Nightly the 40s button will open about:blank with the dialog and the 4000 s button will open a new window with https://www.apple.com/contact/ loaded but without the dialog.
I supposed it is correct for the dialog to not appear, reading through the comments, but just want to make sure.
|
|
||
Comment 12•4 years ago
|
||
(In reply to Timea Cernea [:tbabos] from comment #11)
Hi Gijh,
Can you explain a bit how the fix from Bug 1661030 should work in this case?
Right now on the latest Nightly the 40s button will open about:blank with the dialog and the 4000 s button will open a new window with https://www.apple.com/contact/ loaded but without the dialog.
I supposed it is correct for the dialog to not appear, reading through the comments, but just want to make sure.
The correct thing is for either the dialog to appear but not in front of apple.com, or for apple.com to load and us to not show the dialog, yes.
|
|
||
Comment 13•4 years ago
|
||
Thank you. Marking this as verified-fixed for the latest Firefox Nightly 83.0a1 (2020-09-23) (64-bit) and Beta 82.0b2 (64-bit) on Windows 10, MacOS 10.15 and Ubuntu 20.04.
Clicking on the 40s button will open a new window with about:blank and the dialog.
Clicking on the 4000s button will load the apple.com page in a new window without any dialog (sometimes on Beta it loads about:blank with dialog)
Either way, the dialog is not displayed in front if we have apple.com loaded.
|
|
||
Updated•4 years ago
|
|
|
||
Comment 14•4 years ago
|
||
|
|
Reporter | |
Comment 15•4 years ago
|
||
No didn't host anywhere. In this https://bugs.chromium.org/p/chromium/issues/detail?id=1005596 they have paid bounty
|
|
||
Updated•4 years ago
|
|
|
||
Comment 16•4 years ago
|
||
|
|
||
Updated•4 years ago
|
|
|
||
Updated•3 years ago
|
|
||
Updated•8 months ago
|
Description
•