Since the landing of the code for bug 460882, it is no longer possible to log into the Entrust Certificate management service. Steps to reproduce: 1) Navigate to https://managed.entrust.net/ 2) Try to login (what you enter for username/password is irrelevant) You end up with an error page saying "Firefox can't establish a connection to the server at 0.0.0.0."
Ugh, and we wanted to take bug 460882 on the 1.9.0 branch as well.
Whiteboard: [sg:nse] regression from 460882
mrbkap and I both failed to reproduce this bug on Friday... Any other steps we need to try?
Well I don't get it. This fails for me every time, but works with builds without bug 460882. It definitely fails if I navigate tot he login page and enter guest for both the unique ID and password fields and then click on the Login button.
This might be Mac Java vs. Windows Java, FWIW. I'm trying to find a Windows box to test (and maybe debug) on.
I was about to say that. I am using SUN JAVA SE6 U11 (184.108.40.206) with the new style plug-in.
If it helps you at all, this fails under Linux also using Sun JAVA.
Yeah, I just reproduced on Linux.
Assignee: bent.mozilla → mrbkap
This actually points out a problem that is sg:low -- if a site sets document.domain, references to DOM objects from other scopes won't throw security errors when accessed, like they technically should. A site really has to work at this to make it an XSS attack.
Whiteboard: [sg:nse] regression from 460882 → [sg:low] regression from 460882
(That is, websites need to do a lot of work to allow an evil attacker perform an XSS on them using this bug.)
We need this fixed for beta3, this regression could hurt lots of users. Blake will likely have a fix later today.
Priority: -- → P1
Target Milestone: --- → mozilla1.9.1b3
Created attachment 365093 [details] [diff] [review] Proposed fix So, this fixes this bug by not wrapping same-origin different scope. We decided that it isn't really worth trying to defend against the attack in comment 9 because it's trivial to inject script from one scope the other (could even be a setInterval) and there is literally *nothing* we can do about that. I need to run this under Dromaeo to make sure this doesn't regress performance (which it shouldn't, really).
Created attachment 365094 [details] [diff] [review] Proposed fix Sorry, forgot to refresh after I made some changes.
Created attachment 365095 [details] [diff] [review] Once more Sorry -- the last patch was missing some parentheses.
Comment on attachment 365095 [details] [diff] [review] Once more Looks good to me.
Attachment #365095 - Flags: review?(jst) → review+
10 years ago
Attachment #365095 - Flags: superreview?(bzbarsky) → superreview+
Comment on attachment 365095 [details] [diff] [review] Once more Looks ok, but can we just have a ScopesSameOrigin inline function somewhere that both places can just call?
Created attachment 365104 [details] [diff] [review] With that
Comment on attachment 365104 [details] [diff] [review] With that >+++ b/js/src/xpconnect/src/xpcconvert.cpp >- if (allowNativeWrapper && wrapper->GetScope() != xpcscope) Could just change this to: if (allowNativeWrapper && !xpc_SameOrigin(wrapper->GetScope(), xpcscope) instead of the if/else thing you do. sr=me with that.
Created attachment 365107 [details] [diff] [review] And that This change was trivial enough that I'm just going to stamp r+sr.
Except that last diff doesn't have that change.
Whiteboard: [sg:low] regression from 460882 → [needs landing][sg:low] regression from 460882
Created attachment 365291 [details] [diff] [review] And that Sigh.
Whiteboard: [needs landing][sg:low] regression from 460882 → [fixed?][sg:low] regression from 460882
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Whiteboard: [fixed?][sg:low] regression from 460882 → [sg:low] regression from 460882
Whiteboard: [sg:low] regression from 460882 → [needs 1.9.1 landing][sg:low] regression from 460882
Follow ups on m-c: http://hg.mozilla.org/mozilla-central/rev/ce00f900e758 and http://hg.mozilla.org/mozilla-central/rev/3d0e0bc6a8c4 Everything on 1.9.1: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/8f696b854fcd http://hg.mozilla.org/releases/mozilla-1.9.1/rev/f506287325f7 and http://hg.mozilla.org/releases/mozilla-1.9.1/rev/bb8953ffb790
Whiteboard: [needs 1.9.1 landing][sg:low] regression from 460882 → [sg:low] regression from 460882
Verifying that the original problem I described is fixed under both Linux and Windows using 20090304 nightly builds.
Status: RESOLVED → VERIFIED
Bill, could you also please check with Shiretoko? I'm not able to see the problem with older builds. Thanks!
(In reply to comment #25) > Bill, could you also please check with Shiretoko? I'm not able to see the > problem with older builds. Thanks! I verified this now works correctly under both Windows and Linux using the Firefox 3.1b3 candidate builds.
Thanks Bill. Setting verified1.9.1 based on comment 26.
Keywords: fixed1.9.1 → verified1.9.1
Target Milestone: mozilla1.9.1b3 → mozilla1.9.2a1
Flags: blocking220.127.116.11? → blocking18.104.22.168+
Is there another site to test this with? Entrust.net notes: "As of April 6th, 2009 Entrust has implemented a new authentication system."
This patch also fixed gmail's multiple file upload feature.
I've verified that the multiple file upload feature is working with the 22.214.171.124pre bits.
Keywords: fixed126.96.36.199 → verified188.8.131.52
You need to log in before you can comment on or make changes to this bug.