Embedded HTML documents could request permissions to Top Origin which could lead to spoof attacks on Windows Firefox Nightly
Categories
(Core :: DOM: Security, defect)
Tracking
()
People
(Reporter: proof131072, Assigned: farre)
References
Details
(Keywords: reporter-external, sec-other, testcase-wanted, Whiteboard: [client-bounty-form][domsecurity-active][adv-main132-])
Attachments
(2 files)
Steps to reproduce:
Go to https://codepen.io and follow the step on attached demo video.
We could to prevent permission requests from embedded HTML documents to Top Origin to avoid spoofing attacks.
Assuming https://codepen.io as a legitimate voicechat site in this example, we're getting Microphone permission request from legitimate voicechat site without the real attack site origin that looks like it's actually from the trusted legitimate voicechat site itself.
Comment 1•2 years ago
|
||
Kind of feels like this is a different manifestation of the same underlying issue as bug 1921733 (eg it depends on whether the top level page has the permission first vs top level page doesn't have it and then the child requests it), but I'm not familiar with this code so that might be wrong.
Updated•2 years ago
|
If this had a same behaviour when the top level page has the permission first, I'd agree with that but as you can check from the demo video, we actually already did allow the permission but this is a separate permission request with no origin asking for permission from top level page (two different mic permission icons there).
Comment 3•2 years ago
|
||
Okay, thanks. This is why it would be better if you wrote down the specific steps in the video and talked about why you thought they were relevant rather than just referring us to the video.
Right, my bad, this could actually end up as a duplicate for different reason anyways, but behaviourly it's not the same afaict.
Actually the steps are included in bug 1921818 since I explained the difference between testing with embedded HTML vs XSLT
When you test this issue, please paste this in JS Coding part on the right to test after allowing microphone permission.
navigator.mediaDevices.getUserMedia(
{audio: true}).then(
) :
navigator.getUserMedia(
{audio: true},
);
And then we could test with embedded https://pwning.geniuscoolcat.com/Normal_HTML_Mic.html to reproduce this issue.
This issue occurs with Microphone and Camera permission but not with Location permission, as it'll reveal the correct attacker's origin unlike previous issues, by the way.
| Comment hidden (obsolete) |
As I mentioned, this doesn't work for Geolocation permission unlike previous 2 issues but ideally it'd be nice to prevent cross-origin permission requests entirely.
Updated•2 years ago
|
Comment 8•2 years ago
|
||
Actually the steps are included in bug 1921818 since I explained the difference between testing with embedded HTML vs XSLT
So this is a duplicate then? Are there different steps for this bug?
Updated•2 years ago
|
Updated•2 years ago
|
I explained this behaviour too in that report because I wanted to compare the clear difference for just HTML "Normal_HTML_Mic.html" which causes that spoofing issue with the Top Origin site asking e.g. "allow codepen.io to give Unknown origin access to your microphone" as we can confirm from the attached demo video https://bugzilla.mozilla.org/attachment.cgi?id=9428139 that works for Camera and Mic but not for Geolocation in this report vs XSLT "XSLT_Mic.xml" taking over Top Origin Camera, Mic, Geolocation etc. So that XSLT one is actually only step 3 and this is a different "spoofing" issue.
Step to reproduce:
- Go to https://codepen.io and paste following code on JS coding on the right to allow Microphone access from https://codepen.io which we're assumming it as a legitimate voicechat site in this example.
navigator.mediaDevices.getUserMedia(
{audio: true}).then(
) :
navigator.getUserMedia(
{audio: true},
);
- Check Firefox recognises embedded https://pwning.geniuscoolcat.com/Normal_HTML_Mic.html as an "Unknown origin" with the Top Origin https://codepen.io which could be used for permission spoofing attack.
As I mentioned above, they're not the same as we can confirm by testing this spoof issue alone, but it seems that possibly this behaviour could disappear by the fix.
Updated•2 years ago
|
Comment 10•2 years ago
|
||
The severity field is not set for this bug.
:freddy, could you have a look please?
For more information, please visit BugBot documentation.
Updated•2 years ago
|
Comment 11•1 year ago
|
||
This should be resolved with bug 1921733, right?
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Description
•