Closed Bug 479442 Opened 11 years ago Closed 11 years ago

Can't log in to Entrust Certificate Management Service

Categories

(Core :: XPConnect, defect, P1, major)

defect

Tracking

()

VERIFIED FIXED
mozilla1.9.2a1

People

(Reporter: wgianopoulos, Assigned: mrbkap)

References

()

Details

(Keywords: regression, verified1.9.0.12, verified1.9.1, Whiteboard: [sg:low] regression from 460882)

Attachments

(1 file, 5 obsolete files)

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."
Flags: blocking1.9.2?
Error console reports:

Error: NPMethod called on non-NPObject wrapped JSObject!
Source file: https://managed.entrust.net/javascript/EntrustTruePassClientPrivate.js
Line: 5
Flags: blocking1.9.1?
Ugh, and we wanted to take bug 460882 on the 1.9.0 branch as well.
Blocks: 460882
Flags: wanted1.9.0.x?
Flags: blocking1.9.0.8?
Whiteboard: [sg:nse] regression from 460882
Flags: wanted1.9.0.x?
Flags: wanted1.9.0.x+
Flags: blocking1.9.0.8?
Assignee: nobody → bent.mozilla
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 (6.0.110.3) 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.)
Flags: blocking1.9.1? → blocking1.9.1+
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
Attached patch Proposed fix (obsolete) — Splinter Review
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).
Attachment #365093 - Flags: superreview?(bzbarsky)
Attachment #365093 - Flags: review?(jst)
Attached patch Proposed fix (obsolete) — Splinter Review
Sorry, forgot to refresh after I made some changes.
Attachment #365093 - Attachment is obsolete: true
Attachment #365094 - Flags: superreview?(bzbarsky)
Attachment #365094 - Flags: review?(jst)
Attachment #365093 - Flags: superreview?(bzbarsky)
Attachment #365093 - Flags: review?(jst)
Attached patch Once more (obsolete) — Splinter Review
Sorry -- the last patch was missing some parentheses.
Attachment #365094 - Attachment is obsolete: true
Attachment #365095 - Flags: superreview?(bzbarsky)
Attachment #365095 - Flags: review?(jst)
Attachment #365094 - Flags: superreview?(bzbarsky)
Attachment #365094 - Flags: review?(jst)
Comment on attachment 365095 [details] [diff] [review]
Once more

Looks good to me.
Attachment #365095 - Flags: review?(jst) → review+
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?
Attached patch With that (obsolete) — Splinter Review
Attachment #365095 - Attachment is obsolete: true
Attachment #365104 - Flags: superreview?(bzbarsky)
Attachment #365104 - Flags: review+
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.
Attached patch And that (obsolete) — Splinter Review
This change was trivial enough that I'm just going to stamp r+sr.
Attachment #365104 - Attachment is obsolete: true
Attachment #365107 - Flags: superreview+
Attachment #365107 - Flags: review+
Attachment #365104 - Flags: superreview?(bzbarsky)
Except that last diff doesn't have that change.
Whiteboard: [sg:low] regression from 460882 → [needs landing][sg:low] regression from 460882
Attached patch And thatSplinter Review
Sigh.
Attachment #365107 - Attachment is obsolete: true
Attachment #365291 - Flags: superreview+
Attachment #365291 - Flags: review+
Whiteboard: [needs landing][sg:low] regression from 460882 → [fixed?][sg:low] regression from 460882
Status: NEW → RESOLVED
Closed: 11 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
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!
Flags: blocking1.9.2?
(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.
Target Milestone: mozilla1.9.1b3 → mozilla1.9.2a1
Depends on: 481548
Depends on: 481434
Flags: blocking1.9.0.12?
Flags: blocking1.9.0.12? → blocking1.9.0.12+
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 1.9.0.12pre bits.
Group: core-security
You need to log in before you can comment on or make changes to this bug.