479442 - Can't log in to Entrust Certificate Management Service

Status: VERIFIED FIXED

(Core :: XPConnect, defect, P1)

Description

[Bill Gianopoulos [:WG9s]]

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."

Comment 1

[Bill Gianopoulos [:WG9s]]

Error console reports:

Error: NPMethod called on non-NPObject wrapped JSObject!
Source file: https://managed.entrust.net/javascript/EntrustTruePassClientPrivate.js
Line: 5

Comment 2

[Daniel Veditz [:dveditz]]

Ugh, and we wanted to take bug 460882 on the 1.9.0 branch as well.

Comment 3

[Ben Turner (not reading bugmail, use the needinfo flag!)]

mrbkap and I both failed to reproduce this bug on Friday... Any other steps we need to try?

Comment 4

[Bill Gianopoulos [:WG9s]]

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.

Comment 5

[Blake Kaplan (:mrbkap) (inactive)]

This might be Mac Java vs. Windows Java, FWIW. I'm trying to find a Windows box to test (and maybe debug) on.

Comment 6

[Bill Gianopoulos [:WG9s]]

I was about to say that.  I am using SUN JAVA SE6 U11 (6.0.110.3) with the new style plug-in.

Comment 7

[Bill Gianopoulos [:WG9s]]

If it helps you at all, this fails under Linux also using Sun JAVA.

Comment 8

[Blake Kaplan (:mrbkap) (inactive)]

Yeah, I just reproduced on Linux.

Comment 9

[Blake Kaplan (:mrbkap) (inactive)]

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.

Comment 10

[Blake Kaplan (:mrbkap) (inactive)]

(That is, websites need to do a lot of work to allow an evil attacker perform an XSS on them using this bug.)

Comment 11

[Johnny Stenback (:jst)]

We need this fixed for beta3, this regression could hurt lots of users. Blake will likely have a fix later today.

Comment 12

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: 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).

Comment 13

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: Proposed fix

Sorry, forgot to refresh after I made some changes.

Comment 14

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: Once more

Sorry -- the last patch was missing some parentheses.

Comment 15

[Johnny Stenback (:jst)]

Comment on attachment 365095 [details] [diff] [review]
Once more

Looks good to me.

Comment 16

[Boris Zbarsky [:bzbarsky]]

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?

Comment 17

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: With that

Comment 18

[Boris Zbarsky [:bzbarsky]]

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.

Comment 19

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: And that

This change was trivial enough that I'm just going to stamp r+sr.

Comment 20

[Boris Zbarsky [:bzbarsky]]

Except that last diff doesn't have that change.

Comment 21

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: And that

Sigh.

Comment 22

[Mike Beltzner [:beltzner, not reading bugmail]]

http://hg.mozilla.org/mozilla-central/rev/cee4777f599d

Comment 23

[Blake Kaplan (:mrbkap) (inactive)]

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

Comment 24

[Bill Gianopoulos [:WG9s]]

Verifying that the original problem I described is fixed under both Linux and Windows using 20090304 nightly builds.

Comment 25

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Bill, could you also please check with Shiretoko? I'm not able to see the problem with older builds. Thanks!

Comment 26

[Bill Gianopoulos [:WG9s]]

(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.

Comment 27

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Thanks Bill. Setting verified1.9.1 based on comment 26.

Comment 28

[Al Billings [:abillings - ex-MoCo]]

Is there another site to test this with? Entrust.net notes:

"As of April 6th, 2009 Entrust has implemented a new authentication system."

Comment 29

[Blake Kaplan (:mrbkap) (inactive)]

This patch also fixed gmail's multiple file upload feature.

Comment 30

[Al Billings [:abillings - ex-MoCo]]

I've verified that the multiple file upload feature is working with the 1.9.0.12pre bits.