Closed Bug 253121 Opened 20 years ago Closed 20 years ago

lock icon and certificates spoofable with onunload document.write

Categories

(Core :: Security, defect)

defect
Not set
critical

Tracking

()

VERIFIED FIXED

People

(Reporter: Gavin, Assigned: jst)

References

(Blocks 1 open bug, )

Details

(4 keywords)

Attachments

(5 files, 4 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1

Testcase will be attached 

Reproducible: Always
Steps to Reproduce:
1. Load testcase (attachment coming soon)
2. Right click page -> View Page Info, go to security tab
3. Notice that the site appears to be secure, and the certificate from
https://shellcity.net is shown




See also
Attached file Testcase (obsolete) —
Demonstrates spoof.
Flags: blocking-aviary1.0RC1?
I get at least 4 dialogs warning me about this certificate, at least one of
which says that this isn't the right cert for this site.  Is this really an issue?

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1
That message appears because of a misconfiguration on the shellcity.net site,
which is unrelated to this bug. I picked that site as it was the first I could
think of that had SSL set up. If you can think of another site where ssl is
setup properly you can substitute the URL in the testcase.
Attached file Better testcase
"at least one of which says that this isn't the right cert for this site.  Is
this really an issue?"

This attachment should make the site appear without any warnings.
Attachment #154373 - Attachment is obsolete: true
Okay, that testcase works.  I get the lock icon.  This still isn't a really big
issue, but it should be fixed.
This is a very big issue. People rely on that icon to determine whether or not
the site is "safe". I could make a fake paypal site and use that technique to
make it look as though it is the real paypal site, and collect credit card
numbers. These certificates are critical, their entire purpose is to confirm
that the site you *are* dealing with is in fact the site you *think* you are
dealing with. This vulnerability allows someone to completely bypass this
security measure.
When I view the testcase, I get a lock icon (incorrect and bad), but I see
"bugzilla.mozilla.org" in the URL bar and when I double-click the lock icon.
Stating the obvious: has anyone tested this on seamonkey?

Also, from Jesse's comment, does this really need to be "critical"?  You have to
actually go to "View Certificate" to see the spoofed site's name.  The only
thing actually being spoofed here is the lock icon.
jruderman@gmail.com: 
That is the one spot where the correct site is actually listed. Try clicking
"View" from the security tab to see the full cert. Result: the paypal info is
displayed.

luser_bugzilla@perilith.com:
The actual cert itself is spoofed, so this is more than a cosmetic issue. I am
assuming that the reason that b.m.o is shown in the initial dialog is because
that information is retrieved independantly of the cert. The cert details are
still wrong.
OS -> All

and yeah, this affects Mozilla as well
OS: Windows XP → All
Taking bug.
Assignee: firefox → jst
Comment on attachment 154414 [details] [diff] [review]
Proposed fix. Still needs more testing, but appears to fix the bug.

Darin, does this look good so far?
Attachment #154414 - Flags: review?(darin)
> Darin, does this look good so far?

I haven't reviewed the entire patch, but yeah... major oops that we aren't
propogating the securityInfo from the original channel to the wyciwyg channel :-(
Summary: Mozilla Firefox Certificate Spoofing → lock icon and certificates spoofable with onunload document.write
*** Bug 253215 has been marked as a duplicate of this bug. ***
Can confirm this behaviour also in MacOS X with the following builds:

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; de-DE; rv:1.7) Gecko/20040628
Firefox/0.9.1
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a3) Gecko/20040720
Firefox/0.9.1+
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; de-AT; rv:1.7) Gecko/20040616

Platform->All

Changing Product to Browser, it also affects Mozilla
Component: General → Security: General
Product: Firefox → Browser
Hardware: PC → All
Version: unspecified → Trunk
Comment on attachment 154414 [details] [diff] [review]
Proposed fix. Still needs more testing, but appears to fix the bug.

>+    // document.open() called from another window, loose our cached
>+    // security info

"lose". (or "flush" or something else).
*** Bug 253285 has been marked as a duplicate of this bug. ***
(In reply to comment #18)
> *** Bug 253285 has been marked as a duplicate of this bug. ***

I could not find a matching bug report, so I got worried for a moment. Glad
you're already working on this. 

Here's a summary from the bug I opened, just in case it might help:

---------------------

I got this link from a post in some Israeli forum. The sample spoofing page was
provided by the person who wrote that post (aparently not somebody who likes
Mozilla).

The link for the full-disclosure message is:

http://lists.netsys.com/pipermail/full-disclosure/2004-July/024372.html

That person also provided a test page for the issue (sorry for the message
there, as I mentioned that person does not seem to be a Mozilla lover):

http://uploaded.fresh.co.il/2004/07/27/303883.html

Comment on attachment 154414 [details] [diff] [review]
Proposed fix. Still needs more testing, but appears to fix the bug.

r=darin

this patch makes sense to me, though i'm not sure i fully understand the code
in OpenCommon.	jst: can you explain that part of the patch?
Attachment #154414 - Flags: review+
(In reply to comment #20)
> (From update of attachment 154414 [details] [diff] [review])
> r=darin
> 
> this patch makes sense to me, though i'm not sure i fully understand the code
> in OpenCommon.	jst: can you explain that part of the patch?
> 

I still need to test that, but the idea is to forget the security information we
got from the channel when some *other* window calls document.open() on this
document (anyone can call document.open(), no same-origin checks done there).

IOW, if I do:

  w=window.open("http://www.paypal.com");

w will open and show a locked icon, if I then do:

  w.document.open();
  w.document.write("not secure any more");
  w.document.close();

we should make sure we do *not* display the lock icon any more.

Needs testing still.
Ok, tested that and that case works now too. But after chatting with bz we
decided to change this a bit and in stead of just dropping our reference to our
security info when document.write is called etc, we'll grab the security info
from the calling document in stead, that way, if a secure site does
document.open() on a document that's not secure, it'll become secure (and the
URL bar will reflect the source of the document.open() call etc). New patch
coming up...
Status: NEW → ASSIGNED
Comment on attachment 154499 [details] [diff] [review]
Same as above with code to carry security info over from the caller of document.open().

Requesting reviews. Darin, would you have a look at the additional changes,
it's mostly the same as before, and let me know if my explanation didn't make
sense.
Attachment #154499 - Flags: superreview?(bzbarsky)
Attachment #154499 - Flags: review?(darin)
> we'll grab the security info
> from the calling document in stead, that way, if a secure site does
> document.open() on a document that's not secure, it'll become secure (and the
> URL bar will reflect the source of the document.open() call etc).

wouldn't "mixed-content" make more sense?  calling the content secure when it
may not be entirely secure seems somewhat wrong.
> wouldn't "mixed-content" make more sense?  calling the content secure when it
> may not be entirely secure seems somewhat wrong.

oh, but wait... no vestige of the old document remains in this case, right?
(In reply to comment #26)
> > wouldn't "mixed-content" make more sense?  calling the content secure when it
> > may not be entirely secure seems somewhat wrong.
> 
> oh, but wait... no vestige of the old document remains in this case, right?

Right.
Attachment #154505 - Flags: superreview?(bzbarsky)
Attachment #154505 - Flags: review?(darin)
Attachment #154499 - Attachment is obsolete: true
Attachment #154499 - Flags: superreview?(bzbarsky)
Attachment #154499 - Flags: review?(darin)
Attachment #154414 - Attachment is obsolete: true
Attachment #154414 - Flags: review+
Comment on attachment 154505 [details] [diff] [review]
Same as above, but don't forget the security info in a call to document.open() from the same document.

sr=bzbarsky
Attachment #154505 - Flags: superreview?(bzbarsky) → superreview+
Comment on attachment 154505 [details] [diff] [review]
Same as above, but don't forget the security info in a call to document.open() from the same document.

r=darin, but please add a comment about Reset to explain the securityInfo
juggling in OpenCommon.
Attachment #154505 - Flags: review?(darin) → review+
QA Contact: firefox.general → mozillamonks
Comment on attachment 154516 [details] [diff] [review]
Final patch for checkin (aviary branch)

This diff was missing the security/ changes, new diff coming up.
Attachment #154516 - Attachment is obsolete: true
Fixed on trunk and aviary branch.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Keywords: fixed-aviary1.0
Resolution: --- → FIXED
For the record, the aviary branch diff applies cleanly against the current 1.7
branch.
I think you should land this on the 1.7 branch if you haven't already
Flags: blocking-aviary1.0PR?
Fixed on the 1.7 branch too.
Keywords: fixed1.7
Caillon pointed out that I forgot to rev the IIDs for nsIWyciwygChannel and
nsIDocument, so I did that on all branches.
Comment on attachment 154539 [details] [diff] [review]
For 1.4 branch

a=blizzard for 1.4.3
Attachment #154539 - Flags: approval1.4.3+
(In reply to comment #38)
> Fixed on the 1.7 branch too.

Nit-picking: Keyword should be fixed1.7.2, am i right? :-)
Keywords: fixed1.7fixed1.7.2
*** Bug 253424 has been marked as a duplicate of this bug. ***
This may be worth doing security releases of the branches, especially given the
exposure it got....
(In reply to comment #44)
> This may be worth doing security releases of the branches, especially given the
> exposure it got....

Agreed. I just ran across it on bugtraq, and it could be nice publicity to have
this kind of response time... though it would be nice if we had an easy patching
system going.
In addition to this and bug 249004, it may also be nice to nail bug 250906 as
well. Having all of these taken care of in one release would make many happy,
I'm sure.
Fixed on the 1.7.2 *branch* now too.
Keywords: fixed1.7.2
(In reply to comment #46)
> In addition to this and bug 249004, it may also be nice to nail bug 250906 as
> well. Having all of these taken care of in one release would make many happy,
> I'm sure.

Here's another new security issue that was just opened: 253745

It was reported today by Secunia as "Moderately critical".






Bug #253745 is a duplicate of bug #252198.  
looks good with seamonkey 1.7.2 build 2004-07-31-16-1.7.2
per comment 50, ditto with linux seamonkey 1.7.2, 2004080114 build.
Mac build 1.7.2 20040731 looks good in this regard.
mac firefox 2004080211-0.9.3: due to bug 244479 I cannot view the Security tab
in Page Info. however, no locked padlock appears in the status bar with the test
case, so there's no false indication that a secure site has loaded.
Note: The Common Vulnerabilities and Exposures project (cve.mitre.org) has
assigned the name CAN-2004-0763 to this issue.
Verifying per comment 50 to comment 53.
Status: RESOLVED → VERIFIED
Blocks: lockicon
The bug title has "onunload" in it.

Would it be useful to have the onunload( ) hook disabled by default? It
doesn't have many positive uses.

In other words onunload handlers in web content would not be run unless
the user had gone to the trouble of enabling this feature ...
(In reply to comment #56)

Please note that this bug is VERIFIED FIXED.
I don't know if any further action is required.
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060316 Firefox/1.6a1

The testcase in comment 4 shows:

  1. https://www.paypal.com/ in the URL bar
  2. A black padlock at the right of the status bar
  3. www.paypal.com  at the right of the status bar
  4. A blank page

There was a transient title of 'Spoofer' and some flickering text saying "Enter
...", before the blank page was fully displayed.

Given comment 53 , it might be a good idea for somebody else to check on the
padlock icon and the status bar - perhaps I am on the wrong lines somewhere
and/or need a new profile!
Ben: I cannot reproduce using a trunk or 1.8 branch build on windows. Can you try on a new profile? Is there someone else who can try this on a Mac?
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060317 Firefox/1.6a1

Loading the testcase in comment 4, I see "Insert fake paypal site here. See security icon in lower left.", but the URL bar and status bar indicate that I'm on bugzilla.mozilla.org.

Ben, do you see chrome JS errors in the JavaScript console when you load it?  (You'll have to set javascript.options.showInConsole in about:config to true before testing.)
Irrespective of the javascript config setting, I get this message:

Error: uncaught exception: [Exception... "Component returned failure code: 0x804b003d [nsIDOMNSLocation.reload]"  nsresult: "0x804b003d (<unknown>)"  location: "JS frame :: https://bugzilla.mozilla.org/attachment.cgi?id=154374&action=view :: onunload :: line 1"  data: no]

When I turn on that setting, I see the same as you do. Turning the setting off,
I can reproduce what I said in comment 58 . I will try with a nightly.
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20060321 Firefox/2.0a1

> When I turn on that setting, I see the same as you do. Turning the setting off,
> I can reproduce what I said in comment 58 . I will try with a nightly.

Testing with the Bon Echo alpha (and a new profile) shows the "Insert fake paypal site here. See security icon in lower left." message in full, but the status
bar correctly says "bugzilla.mozilla.org". Nothing in the javascript console, and in general the same as  comment 60 .
You need to log in before you can comment on or make changes to this bug.