68.87 KB, image/jpeg
dougt, who should own?
I just verified this issue works as reported. Just to summarize the attack scenario above: - User must be currently logged into the find.firefox.com website - User is coerced into visiting a malicious website, and then coerced to click 3 times The impact is wiping the device. Potentially locking the phone could be an impact, but this requires setting a PIN so less likely attack vector (clicks alone don't work). Note that the user has to already be logged in. Even with a password manager which might allow clickjacking the login screen as well, the login sequence breaks when it is framed. The simplest fix would be to set the x-frame-options header to DENY for this domain. Yvan, Joe - any idea who owns this infrastructure? If you're not sure, just assign back to me and I'll chase for an owner.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Paul, I have no idea who owns it. I'll try to find the owner and get the fix you suggested implemented.
Paul, Cloud services owns this. Recommend assigning to Yvan.
Assignee: yboily → jrconlin
This appears to be on the web
Jeremy, can you add the list of recommended headers from https://www.owasp.org/index.php/List_of_useful_HTTP_headers to the STAGE deployment servers of FMD? We will test and verify that there's no additional customer impact before rolling this change to PRODUCTION.
We are running straight Go on the FMD servers, so we can either start fronting the services with nginx or add the headers to the app. Fronting the app with nginx would need more QA. jr, do you have a preference?
Flags: needinfo?(oremj) → needinfo?(jrconlin)
Wait, I know that we're running straight to go for / but for /static/* components (/bower*, /style/*, etc.) we shouldn't be using the "use_insecure_static" option. Those should be handled by something else like nginx. I'm adding a patch to the go code to handle the root paths, and see about confirming the source of the additional site files.
(In reply to JR Conlin [:jrconlin,:jconlin] from comment #13) > Wait, I know that we're running straight to go for / but for /static/* > components (/bower*, /style/*, etc.) we shouldn't be using the > "use_insecure_static" option. Those should be handled by something else like > nginx. > > I'm adding a patch to the go code to handle the root paths, and see about > confirming the source of the additional site files. If we want them both to be on the same domain, it is all or nothing. We'd have to host the static files with nginx and proxy /.
Added headers to all outbound server responses: https://github.com/mozilla-services/FindMyDevice/pull/327 also increased the STS delay per bug 1143977
Hi, I have checked the fix if it was online or not and found that it is vulnerable till now, so is the patch online or not being pushed yet?! Thanks
We're a bit tight on QA resources. The fix is working it's way through stage at the moment to ensure that we don't break any devices or interfaces that are already deployed.
Flags: sec-bounty? → sec-bounty+
JR: is this bug fixed or not? Hopefully the former because it's public now http://seclists.org/fulldisclosure/2015/Oct/82
Flags: needinfo?(yboily) → needinfo?(jrconlin)
I saw that X-Frame-Headers: deny was set on the page, earlier today.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Following up per sec request, the fix was applied to the code Mar 18 deployed to STAGE https://bugzilla.mozilla.org/show_bug.cgi?id=1146226 And deployed to Prod shortly there after. Unfortunately, I don't have a bug handy for that deployment since it came from QA. I will attempt to track that down. The absolute latest it was deployed was part of 1.4.7 (the latest deployed version) on 04/21 https://bugzilla.mozilla.org/show_bug.cgi?id=1156348
Hi Guys, I'm requesting a CVE for this!.
(In reply to Mohamed A. Baset from comment #23) > Hi Guys, I'm requesting a CVE for this!. From whom?
Maybe Mozilla can work along with MITRE to get this. or should i report it individually to them?
CVEs are for publicly released software packages, not for services or websites. Since the vulnerability lies in the service and not the software (ie, FxOS), there wouldn't be a CVE issued for something like this.
Ravi - this was a configuration issue on a server. It was fixed months ago - it has nothing to do with 2.2r as per comment 22.
blocking-b2g: 2.2r+ → ---
Paul, thanks for the explanation.
Product: Cloud Services → Cloud Services Graveyard
You need to log in before you can comment on or make changes to this bug.