Closed
Bug 253121
Opened 20 years ago
Closed 20 years ago
lock icon and certificates spoofable with onunload document.write
Categories
(Core :: Security, defect)
Core
Security
Tracking
()
VERIFIED
FIXED
People
(Reporter: Gavin, Assigned: jst)
References
(Blocks 1 open bug, )
Details
(4 keywords)
Attachments
(5 files, 4 obsolete files)
(deleted),
text/html
|
Details | |
(deleted),
patch
|
darin.moz
:
review+
bzbarsky
:
superreview+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
caillon
:
approval1.4.3+
|
Details | Diff | Splinter Review |
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
Reporter | ||
Comment 1•20 years ago
|
||
Demonstrates spoof.
Reporter | ||
Updated•20 years ago
|
Flags: blocking-aviary1.0RC1?
Comment 2•20 years ago
|
||
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
Reporter | ||
Comment 3•20 years ago
|
||
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.
Reporter | ||
Comment 4•20 years ago
|
||
"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
Comment 5•20 years ago
|
||
Okay, that testcase works. I get the lock icon. This still isn't a really big
issue, but it should be fixed.
Reporter | ||
Comment 6•20 years ago
|
||
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•20 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.
Comment 8•20 years ago
|
||
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.
Reporter | ||
Comment 9•20 years ago
|
||
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.
Assignee | ||
Comment 12•20 years ago
|
||
Assignee | ||
Comment 13•20 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•20 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•20 years ago
|
Summary: Mozilla Firefox Certificate Spoofing → lock icon and certificates spoofable with onunload document.write
Comment 15•20 years ago
|
||
*** Bug 253215 has been marked as a duplicate of this bug. ***
Comment 16•20 years ago
|
||
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•20 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•20 years ago
|
||
*** Bug 253285 has been marked as a duplicate of this bug. ***
Comment 19•20 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•20 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•20 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•20 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•20 years ago
|
||
Assignee | ||
Comment 24•20 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•20 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•20 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•20 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•20 years ago
|
||
Assignee | ||
Updated•20 years ago
|
Attachment #154505 -
Flags: superreview?(bzbarsky)
Attachment #154505 -
Flags: review?(darin)
Assignee | ||
Updated•20 years ago
|
Attachment #154499 -
Attachment is obsolete: true
Attachment #154499 -
Flags: superreview?(bzbarsky)
Attachment #154499 -
Flags: review?(darin)
Assignee | ||
Updated•20 years ago
|
Attachment #154414 -
Attachment is obsolete: true
Attachment #154414 -
Flags: review+
Comment 29•20 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.
sr=bzbarsky
Attachment #154505 -
Flags: superreview?(bzbarsky) → superreview+
Comment 30•20 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•20 years ago
|
QA Contact: firefox.general → mozillamonks
Assignee | ||
Comment 31•20 years ago
|
||
Assignee | ||
Comment 32•20 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•20 years ago
|
||
Assignee | ||
Comment 34•20 years ago
|
||
Assignee | ||
Comment 35•20 years ago
|
||
Fixed on trunk and aviary branch.
Assignee | ||
Comment 36•20 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
Reporter | ||
Updated•20 years ago
|
Flags: blocking-aviary1.0PR?
Assignee | ||
Comment 39•20 years ago
|
||
Caillon pointed out that I forgot to rev the IIDs for nsIWyciwygChannel and
nsIDocument, so I did that on all branches.
Comment 40•20 years ago
|
||
Comment 41•20 years ago
|
||
Comment on attachment 154539 [details] [diff] [review]
For 1.4 branch
a=blizzard for 1.4.3
Attachment #154539 -
Flags: approval1.4.3+
Updated•20 years ago
|
Keywords: fixed1.4.3
Comment 42•20 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•20 years ago
|
Keywords: fixed1.7 → fixed1.7.2
Comment 43•20 years ago
|
||
*** Bug 253424 has been marked as a duplicate of this bug. ***
Comment 44•20 years ago
|
||
This may be worth doing security releases of the branches, especially given the
exposure it got....
Comment 45•20 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•20 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.
Comment 48•20 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•20 years ago
|
||
Bug #253745 is a duplicate of bug #252198.
Comment 50•20 years ago
|
||
looks good with seamonkey 1.7.2 build 2004-07-31-16-1.7.2
Comment 51•20 years ago
|
||
per comment 50, ditto with linux seamonkey 1.7.2, 2004080114 build.
Comment 52•20 years ago
|
||
Mac build 1.7.2 20040731 looks good in this regard.
Comment 53•20 years ago
|
||
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•20 years ago
|
||
Note: The Common Vulnerabilities and Exposures project (cve.mitre.org) has
assigned the name CAN-2004-0763 to this issue.
Reporter | ||
Comment 55•20 years ago
|
||
Verifying per comment 50 to comment 53.
Status: RESOLVED → VERIFIED
Comment 56•20 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 ...
Comment 57•20 years ago
|
||
(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•19 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!
Comment 59•19 years ago
|
||
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•19 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•19 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•19 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.
Description
•