lock icon and certificates spoofable with onunload document.write

VERIFIED FIXED

Status

()

Core
Security
--
critical
VERIFIED FIXED
13 years ago
12 years ago

People

(Reporter: Gavin, Assigned: jst)

Tracking

(Blocks: 1 bug, 4 keywords)

Trunk
fixed-aviary1.0, fixed1.4.3, fixed1.7.2, fixed1.7.5
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(5 attachments, 4 obsolete attachments)

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
Created attachment 154373 [details]
Testcase

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.
Created attachment 154374 [details]
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.

Comment 7

13 years ago
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.

Comment 10

13 years ago
OS -> All

and yeah, this affects Mozilla as well
OS: Windows XP → All
(Assignee)

Comment 11

13 years ago
Taking bug.
Assignee: firefox → jst
(Assignee)

Comment 12

13 years ago
Created attachment 154414 [details] [diff] [review]
Proposed fix. Still needs more testing, but appears to fix the bug.
(Assignee)

Comment 13

13 years ago
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)

Comment 14

13 years ago
> 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 :-(

Updated

13 years ago
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 17

13 years ago
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).

Comment 18

13 years ago
*** Bug 253285 has been marked as a duplicate of this bug. ***

Comment 19

13 years ago
(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 20

13 years ago
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+
(Assignee)

Comment 21

13 years ago
(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.
(Assignee)

Comment 22

13 years ago
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
(Assignee)

Comment 23

13 years ago
Created attachment 154499 [details] [diff] [review]
Same as above with code to carry security info over from the caller of document.open().
(Assignee)

Comment 24

13 years ago
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)

Comment 25

13 years ago
> 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.

Comment 26

13 years ago
> 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?
(Assignee)

Comment 27

13 years ago
(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.
(Assignee)

Comment 28

13 years ago
Created 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.
(Assignee)

Updated

13 years ago
Attachment #154505 - Flags: superreview?(bzbarsky)
Attachment #154505 - Flags: review?(darin)
(Assignee)

Updated

13 years ago
Attachment #154499 - Attachment is obsolete: true
Attachment #154499 - Flags: superreview?(bzbarsky)
Attachment #154499 - Flags: review?(darin)
(Assignee)

Updated

13 years ago
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 30

13 years ago
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+

Updated

13 years ago
QA Contact: firefox.general → mozillamonks
(Assignee)

Comment 31

13 years ago
Created attachment 154516 [details] [diff] [review]
Final patch for checkin (aviary branch)
(Assignee)

Comment 32

13 years ago
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
(Assignee)

Comment 33

13 years ago
Created attachment 154525 [details] [diff] [review]
Final patch for checkin (aviary branch)
(Assignee)

Comment 34

13 years ago
Created attachment 154526 [details] [diff] [review]
Final patch for checkin (trunk)
(Assignee)

Comment 35

13 years ago
Fixed on trunk and aviary branch.
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Keywords: fixed-aviary1.0
Resolution: --- → FIXED
(Assignee)

Comment 36

13 years ago
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?
(Assignee)

Comment 38

13 years ago
Fixed on the 1.7 branch too.
Keywords: fixed1.7
(Assignee)

Comment 39

13 years ago
Caillon pointed out that I forgot to rev the IIDs for nsIWyciwygChannel and
nsIDocument, so I did that on all branches.
Created attachment 154539 [details] [diff] [review]
For 1.4 branch
Comment on attachment 154539 [details] [diff] [review]
For 1.4 branch

a=blizzard for 1.4.3
Attachment #154539 - Flags: approval1.4.3+
Keywords: fixed1.4.3

Comment 42

13 years ago
(In reply to comment #38)
> Fixed on the 1.7 branch too.

Nit-picking: Keyword should be fixed1.7.2, am i right? :-)

Updated

13 years ago
Keywords: fixed1.7 → fixed1.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....

Comment 45

13 years ago
(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.

Comment 46

13 years ago
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.
(Assignee)

Comment 47

13 years ago
Fixed on the 1.7.2 *branch* now too.
Keywords: fixed1.7.2

Comment 48

13 years ago
(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".






Comment 49

13 years ago
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.

Comment 54

13 years ago
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: 130949

Comment 56

13 years ago
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.

Comment 58

12 years ago
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?

Comment 60

12 years ago
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.)

Comment 61

12 years ago
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.

Comment 62

12 years ago
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.