Last Comment Bug 451898 - (CVE-2009-2654) URL spoofing bug involving Firefox's error pages and document.write
(CVE-2009-2654)
: URL spoofing bug involving Firefox's error pages and document.write
Status: VERIFIED FIXED
[sg:moderate] spoof
: testcase, verified1.9.0.13, verified1.9.0.14, verified1.9.1
Product: Core
Classification: Components
Component: Document Navigation (show other bugs)
: Trunk
: All All
: -- normal (vote)
: mozilla1.9.2a1
Assigned To: Boris Zbarsky [:bz] (Out June 25-July 6)
:
Mentors:
http://es.geocities.com/jplopezy/prue...
Depends on:
Blocks: CVE-2009-3985
  Show dependency treegraph
 
Reported: 2008-08-23 17:24 PDT by Juan Pablo Lopez Yacubian
Modified: 2010-01-26 07:51 PST (History)
28 users (show)
benjamin: blocking1.9.1-
benjamin: wanted1.9.1+
samuel.sidler+old: blocking1.9.0.14+
samuel.sidler+old: wanted1.9.0.x+
dveditz: blocking1.8.1.next-
dveditz: wanted1.8.1.x+
hskupin: in‑testsuite?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
.2+
.2-fixed


Attachments
testcase (280 bytes, text/html)
2008-08-23 21:13 PDT, Jesse Ruderman
no flags Details
Fix (1015 bytes, patch)
2009-07-28 13:27 PDT, Boris Zbarsky [:bz] (Out June 25-July 6)
cbiesinger: review+
samuel.sidler+old: approval1.9.1.2+
samuel.sidler+old: approval1.9.0.14+
Details | Diff | Review
1.8 version (754 bytes, patch)
2009-08-20 01:20 PDT, Martin Stránský
no flags Details | Diff | Review
screen shot (88.93 KB, image/jpeg)
2009-10-13 07:46 PDT, Honza Bambas (:mayhemer)
no flags Details

Description Juan Pablo Lopez Yacubian 2008-08-23 17:24:30 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.0.1) Gecko/2008070208 Firefox/1.5.0.xx Alexa Toolbar;MEGAUPLOAD 1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.0.1) Gecko/2008070208 Firefox/1.5.0.xx Alexa Toolbar;MEGAUPLOAD 1.0

The problem originated, when you try to create a link with javascript (window.open). When you enter an incorrect address seems that the firefox can not translate the address web and display the web address in a blank page.
This blank page can be changed with javascript making can create an attack of the type spoofig.

Reproducible: Always

Steps to Reproduce:
1.Create a html file with a special javascript
2.Open page
Actual Results:  
One can visualize the address unresolved and the blank page amended.


In itself, the mistake is simple. The problem is that with javascript window can be changed by altering the content and halting the loading of the page.
Comment 1 Jesse Ruderman 2008-08-23 21:13:52 PDT
Created attachment 335225 [details]
testcase

(modified slightly to make the document.written HTML more sane)
Comment 7 Boris Zbarsky [:bz] (Out June 25-July 6) 2008-09-26 08:42:59 PDT
ccing some folks who've dealt with error pages in the past and might have bright ideas here.
Comment 8 Michal Novotny (:michal) 2008-10-03 16:03:15 PDT
(In reply to comment #6)
> window.open() followed by modifying the DOM or document.writing into the
> resulting document needs to work.

When this is exactly allowed? For example following code throws error in console "Permission denied to get property Window.document"
  
  function spoof()
  {
    a = window.open("http://www.xxx.xyz%")
    setTimeout(do_write, 0);
  }

  function do_write()
  {
    a.document.write("<title>test</title>")
    a.document.write("<H1>FAKE PAGE</h1>")
    a.stop ();
  }
Comment 9 Michal Novotny (:michal) 2008-10-03 17:12:41 PDT
I've noticed that the bug doesn't appear if I change "http://www.google.com.ar%" in the testcase to some nonexistent domain (e.g. "www.xxx.xyz"). I've compared both cases and the difference is that '%' isn't allowed in host names and nsHttpChannel::Connect() fails immediately, error page starts loading and new SHEntry is put into mLSHE at http://mxr.mozilla.org/mozilla-central/source/docshell/base/nsDocShell.cpp#8096. Ignore different line numbers in my backtrace, I've put a lot of logging into nsDocShell.cpp...

#0  nsDocShell::OnNewURI (this=0xf60f7d80, aURI=0xee49bbe0, aChannel=0xf1a0b090, aLoadType=1, aFireOnLocationChange=1, aAddToGlobalHistory=0)
    at /opt/moz/TRUNK_new3/mozilla/docshell/base/nsDocShell.cpp:8244
#1  0x015a1917 in nsDocShell::OnLoadingSite (this=0xf60f7d80, aChannel=0xf1a0b090, aFireOnLocationChange=1, aAddToGlobalHistory=0)
    at /opt/moz/TRUNK_new3/mozilla/docshell/base/nsDocShell.cpp:8289
#2  0x015aac47 in nsDocShell::LoadErrorPage (this=0xf60f7d80, aURI=0xee49bbe0, aURL=0x0, aErrorPage=0xffebc294 "neterror", aErrorType=0xffebc158, 
    aDescription=0xffebc0c4, aCSSClass=0xffebc2e8 "", aFailedChannel=0xf1a0b090) at /opt/moz/TRUNK_new3/mozilla/docshell/base/nsDocShell.cpp:3284
#3  0x015ac579 in nsDocShell::DisplayLoadError (this=0xf60f7d80, aError=2152398878, aURI=0xee49bbe0, aURL=0x0, aFailedChannel=0xf1a0b090)
    at /opt/moz/TRUNK_new3/mozilla/docshell/base/nsDocShell.cpp:3231
#4  0x015b88b7 in nsWebShell::EndPageLoad (this=0xf60f7d80, aProgress=0xf60f7d94, channel=0xf1a0b090, aStatus=2152398878)
    at /opt/moz/TRUNK_new3/mozilla/docshell/base/nsWebShell.cpp:1184
#5  0x015a2e91 in nsDocShell::OnStateChange (this=0xf60f7d80, aProgress=0xf60f7d94, aRequest=0xf1a0b090, aStateFlags=131088, aStatus=2152398878)
    at /opt/moz/TRUNK_new3/mozilla/docshell/base/nsDocShell.cpp:5103
#6  0x015ce4e4 in nsDocLoader::FireOnStateChange (this=0xf60f7d80, aProgress=0xf60f7d94, aRequest=0xf1a0b090, aStateFlags=131088, aStatus=2152398878)
    at /opt/moz/TRUNK_new3/mozilla/uriloader/base/nsDocLoader.cpp:1235
#7  0x015cf12d in nsDocLoader::doStopDocumentLoad (this=0xf60f7d80, request=0xf1a0b090, aStatus=2152398878)
    at /opt/moz/TRUNK_new3/mozilla/uriloader/base/nsDocLoader.cpp:858
#8  0x015cf323 in nsDocLoader::DocLoaderIsEmpty (this=0xf60f7d80) at /opt/moz/TRUNK_new3/mozilla/uriloader/base/nsDocLoader.cpp:763
#9  0x015cfa0d in nsDocLoader::OnStopRequest (this=0xf60f7d80, aRequest=0xf1a0b090, aCtxt=0x0, aStatus=2152398878)
    at /opt/moz/TRUNK_new3/mozilla/uriloader/base/nsDocLoader.cpp:679
#10 0x00b8931f in nsLoadGroup::RemoveRequest (this=0xec90f9b0, request=0xf1a0b090, ctxt=0x0, aStatus=2152398878)
    at /opt/moz/TRUNK_new3/mozilla/netwerk/base/src/nsLoadGroup.cpp:688
#11 0x00c554d8 in nsHttpChannel::AsyncAbort (this=0xf1a0b060, status=2152398878) at /opt/moz/TRUNK_new3/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp:363
#12 0x00c55979 in nsHttpChannel::AsyncOpen (this=0xf1a0b060, listener=0xee637c40, context=0x0)
    at /opt/moz/TRUNK_new3/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp:3721
#13 0x015c864b in nsURILoader::OpenURI (this=0xf62d4ca0, channel=0xf1a0b090, aIsContentPreferred=0, aWindowContext=0xf60f7d98)
    at /opt/moz/TRUNK_new3/mozilla/uriloader/base/nsURILoader.cpp:840
#14 0x015987fc in nsDocShell::DoChannelLoad (this=0xf60f7d80, aChannel=0xf1a0b090, aURILoader=0xf62d4ca0, aBypassClassifier=0)
    at /opt/moz/TRUNK_new3/mozilla/docshell/base/nsDocShell.cpp:7843
#15 0x0159dc16 in nsDocShell::DoURILoad (this=0xf60f7d80, aURI=0xee49bbe0, aReferrerURI=0xee49b9d0, aSendReferrer=1, aOwner=0xec96ad30, aTypeHint=0x0, 
    aPostData=0x0, aHeadersData=0x0, aFirstParty=1, aDocShell=0x0, aRequest=0xffebcea4, aIsNewWindowTarget=1, aBypassClassifier=0)
    at /opt/moz/TRUNK_new3/mozilla/docshell/base/nsDocShell.cpp:7689
#16 0x015a603f in nsDocShell::InternalLoad (this=0xf60f7d80, aURI=0xee49bbe0, aReferrer=0xee49b9d0, aOwner=0xec96ad30, aFlags=8, aWindowTarget=0xeed28576, 
    aTypeHint=0x0, aPostData=0x0, aHeadersData=0x0, aLoadType=1, aSHEntry=0x0, aFirstParty=1, aDocShell=0x0, aRequest=0x0)
    at /opt/moz/TRUNK_new3/mozilla/docshell/base/nsDocShell.cpp:7395
#17 0x0159e9d7 in nsDocShell::LoadURI (this=0xf60f7d80, aURI=0xee49bbe0, aLoadInfo=0xee531740, aLoadFlags=16384, aFirstParty=1)
    at /opt/moz/TRUNK_new3/mozilla/docshell/base/nsDocShell.cpp:909
#18 0x01607f4f in nsWindowWatcher::OpenWindowJSInternal (this=0xf62841f0, aParent=0xf0118c80, aUrl=0xec92cb08 "http://www.xxx.xyz%", aName=0x0, aFeatures=0x0, 
    aDialog=0, argv=0x0, aCalledFromJS=1, _retval=0xffebd7b8) at /opt/moz/TRUNK_new3/mozilla/embedding/components/windowwatcher/src/nsWindowWatcher.cpp:909
#19 0x01608466 in nsWindowWatcher::OpenWindowJS (this=0xf62841f0, aParent=0xf0118c80, aUrl=0xec92cb08 "http://www.xxx.xyz%", aName=0x0, aFeatures=0x0, aDialog=0, 
    argv=0x0, _retval=0xffebd7b8) at /opt/moz/TRUNK_new3/mozilla/embedding/components/windowwatcher/src/nsWindowWatcher.cpp:484
#20 0x012c5342 in nsGlobalWindow::OpenInternal (this=0xf0118c80, aUrl=@0xffebd9cc, aName=@0xffebd938, aOptions=@0xffebd8a4, aDialog=0, aContentModal=0, 
    aCalledNoScript=0, aDoJSFixups=1, argv=0x0, aExtraArgument=0x0, aCalleePrincipal=0xec96ad30, aJSCallerContext=0xef553580, aReturn=0xffebdc10)
    at /opt/moz/TRUNK_new3/mozilla/dom/src/base/nsGlobalWindow.cpp:7390
#21 0x012c661f in nsGlobalWindow::Open (this=0xf0118c80, _retval=0xffebdc10) at /opt/moz/TRUNK_new3/mozilla/dom/src/base/nsGlobalWindow.cpp:5059

Then when a.document.write("<title>test</title>") is called, URL isn't rewritten because of mLSHE in condition at http://mxr.mozilla.org/mozilla-central/source/docshell/base/nsDocShell.cpp#5020.

#0  nsDocShell::OnStateChange (this=0xf60f8140, aProgress=0xf60f8154, aRequest=0xec910120, aStateFlags=983041, aStatus=0)
    at /opt/moz/TRUNK_new3/mozilla/docshell/base/nsDocShell.cpp:5045
#1  0x015ce4e4 in nsDocLoader::FireOnStateChange (this=0xf60f8140, aProgress=0xf60f8154, aRequest=0xec910120, aStateFlags=983041, aStatus=0)
    at /opt/moz/TRUNK_new3/mozilla/uriloader/base/nsDocLoader.cpp:1235
#2  0x015cfb83 in nsDocLoader::doStartDocumentLoad (this=0xf60f8140) at /opt/moz/TRUNK_new3/mozilla/uriloader/base/nsDocLoader.cpp:796
#3  0x015cfddc in nsDocLoader::OnStartRequest (this=0xf60f8140, request=0xec910120, aCtxt=0x0) at /opt/moz/TRUNK_new3/mozilla/uriloader/base/nsDocLoader.cpp:528
#4  0x00b896b0 in nsLoadGroup::AddRequest (this=0xec90f080, request=0xec910120, ctxt=0x0) at /opt/moz/TRUNK_new3/mozilla/netwerk/base/src/nsLoadGroup.cpp:603
#5  0x01195a23 in nsHTMLDocument::CreateAndAddWyciwygChannel (this=0xec971800) at /opt/moz/TRUNK_new3/mozilla/content/html/document/src/nsHTMLDocument.cpp:3701
#6  0x0119994a in nsHTMLDocument::OpenCommon (this=0xec971800, aContentType=@0xffebd8f4, aReplace=0)
    at /opt/moz/TRUNK_new3/mozilla/content/html/document/src/nsHTMLDocument.cpp:2324
#7  0x01199a49 in nsHTMLDocument::Open (this=0xec971800, aContentType=@0xffebd8f4, aReplace=0, aReturn=0xffebd8ec)
    at /opt/moz/TRUNK_new3/mozilla/content/html/document/src/nsHTMLDocument.cpp:2342
#8  0x011913c5 in nsHTMLDocument::Open (this=0xec971800) at /opt/moz/TRUNK_new3/mozilla/content/html/document/src/nsHTMLDocument.cpp:2335
#9  0x01197b66 in nsHTMLDocument::WriteCommon (this=0xec971800, aText=@0xffebda40, aNewlineTerminate=0)
    at /opt/moz/TRUNK_new3/mozilla/content/html/document/src/nsHTMLDocument.cpp:2443
#10 0x011980f2 in nsHTMLDocument::ScriptWriteCommon (this=0xec971800, aNewlineTerminate=0)
    at /opt/moz/TRUNK_new3/mozilla/content/html/document/src/nsHTMLDocument.cpp:2535
#11 0x011982c9 in nsHTMLDocument::Write (this=0xec971800) at /opt/moz/TRUNK_new3/mozilla/content/html/document/src/nsHTMLDocument.cpp:2563

If I set mLSHE=0 manually in GDB then URL is set correctly. But I'm not sure, how exactly to fix this bug. Should we change the condition? Or should a.document.write() fail with "Permission denied to get property Window.document" because loading of error page is already in progress?
Comment 10 Boris Zbarsky [:bz] (Out June 25-July 6) 2008-10-03 17:14:22 PDT
Don't set a timeout.  Do your stuff immediately after the open() call.  And if you want, don't pass a URI to window.open().  Then write stuff into it.  Then set its location.
Comment 11 Boris Zbarsky [:bz] (Out June 25-July 6) 2008-10-03 17:14:34 PDT
Need a bit to think about comment 9.
Comment 12 Boris Zbarsky [:bz] (Out June 25-July 6) 2008-10-21 13:00:20 PDT
OK, I see.  So the key is that the document.write happens in the middle of the error page load, right?  At a point after we have mLSHE but before the document the script sees is the error page document.

I guess for normal loads we Embed() the new viewer right after the OnLoadingSite call that sets up mLSHE, so the mLSHE being present in fact corresponds to our document being the new document.
Comment 13 Boris Zbarsky [:bz] (Out June 25-July 6) 2008-10-21 13:46:23 PDT
Hrm.  So how come mLoadType is LOAD_NORMAL when we get here, because we manually set it in OpenCommon.

Would it work to just Stop() the docshell in OpenCommon()?  Or to have PrepareForNewContentModel() kill off a pending error page load?
Comment 14 Michal Novotny (:michal) 2008-10-23 15:01:28 PDT
(In reply to comment #12)
> OK, I see.  So the key is that the document.write happens in the middle of the
> error page load, right?  At a point after we have mLSHE but before the document
> the script sees is the error page document.

I think so.

> I guess for normal loads we Embed() the new viewer right after the
> OnLoadingSite call that sets up mLSHE, so the mLSHE being present in fact
> corresponds to our document being the new document.

Yes, this is in nsDocShell::CreateContentViewer().


(In reply to comment #13)
> Hrm.  So how come mLoadType is LOAD_NORMAL when we get here, because we
> manually set it in OpenCommon.

It is OK, or not? mLoadType is LOAD_ERROR_PAGE until it is set to LOAD_NORMAL in OpenCommon() when the document is rewritten in javascript...

> Would it work to just Stop() the docshell in OpenCommon()?  Or to have

I've tried that and calling Stop() in OpenCommon() doesn't help.

> PrepareForNewContentModel() kill off a pending error page load?

Hmm, maybe, but how to do it correctly? Calling Stop() at this place doesn't work either.
Comment 15 Boris Zbarsky [:bz] (Out June 25-July 6) 2008-10-23 18:21:40 PDT
Hrm.  I'm not sure I know, if Stop() doesn't work.   Maybe mail biesi?
Comment 16 Juan Pablo Lopez Yacubian 2009-04-27 06:40:55 PDT
what happend with this bug?
Comment 17 Boris Zbarsky [:bz] (Out June 25-July 6) 2009-04-27 18:49:56 PDT
Nothing, so far.  Not sure whether Michal ever mailed biesi.

What about making document.open() throw if the docshell is in the middle of an error page load?
Comment 18 Michal Novotny (:michal) 2009-04-28 00:09:42 PDT
(In reply to comment #17)
> Nothing, so far.  Not sure whether Michal ever mailed biesi.

I've sent the mail but received no reply :-/

> What about making document.open() throw if the docshell is in the middle of an
> error page load?

I'll try...
Comment 19 Michal Novotny (:michal) 2009-04-28 17:56:36 PDT
OK, throwing error in nsHTMLDocument::OpenCommon() when error page is loading helps. But how to correctly find out that we are loading the page right now? mBusyFlags in docshell isn't set correctly at this point. Is it always when mLSHE is non-null? If yes, then new method in nsIDocShell is needed to check this condition :-/
Comment 20 Boris Zbarsky [:bz] (Out June 25-July 6) 2009-04-28 21:33:47 PDT
Hmm.  I guess just looking at the load type is not good enough because the error page might be done loading and in that case we shouldn't prevent the write()?

I guess that argument can apply to the loading case too.  So maybe we should really figure out why the Stop() approach didn't work.
Comment 21 Samuel Sidler (old account; do not CC) 2009-07-27 14:37:14 PDT
This bug was made public by the reporter on July 24: http://www.securityfocus.com/archive/1/505242/30/0/threaded
Comment 22 Samuel Sidler (old account; do not CC) 2009-07-27 15:38:51 PDT
Boris said he'd look at this since Michal is out.
Comment 23 Reed Loden [:reed] (use needinfo?) 2009-07-27 19:41:13 PDT
http://es.geocities.com/jplopezy/firefoxspoofing.html is another testcase.
Comment 24 Reed Loden [:reed] (use needinfo?) 2009-07-27 20:41:55 PDT
(In reply to comment #23)
> http://es.geocities.com/jplopezy/firefoxspoofing.html is another testcase.

except that just seems to be Jesse's testcase.
Comment 25 Reed Loden [:reed] (use needinfo?) 2009-07-28 00:30:46 PDT
(In reply to comment #24)
> (In reply to comment #23)
> > http://es.geocities.com/jplopezy/firefoxspoofing.html is another testcase.
> 
> except that just seems to be Jesse's testcase.

Never mind. I misread.
Comment 26 Boris Zbarsky [:bz] (Out June 25-July 6) 2009-07-28 12:57:30 PDT
Quick brain-dump:

The basic issue is as diagnosed in comment 9.  Stop() doesn't help because it doesn't do anything with mLSHE directly.  Error pages never clear mLSHE because they never actually hit EndPageLoad.

I talked this over with biesi, and we think the safest fix is to just have Stop() reset mLSHE for error page loads to null.  Building and testing that now.
Comment 27 Boris Zbarsky [:bz] (Out June 25-July 6) 2009-07-28 13:27:17 PDT
Created attachment 391176 [details] [diff] [review]
Fix

I'd welcome someone figuring out a way to automatically test this....
Comment 28 Lorenz H.-S. 2009-07-29 05:11:00 PDT
mmh. it does not work for me! The URL in the test case says "https://bug451898.bugzilla.mozilla.org/attachment.cgi?id=335225" in the tab that is opened. Nor does the test case from geocities work (not that there be much differnce, but still). Maybe it's one of my addons? (Adblock Plus, DownloadHelper, Linkification, Locationbar², NoScript, SkipScreen, TACO, Xmarks)
Comment 29 Boris Zbarsky [:bz] (Out June 25-July 6) 2009-07-29 10:40:37 PDT
Pushed http://hg.mozilla.org/mozilla-central/rev/82f131218d09

Lorenz, it would be quite easy for extensions to interfere with this, as well as with a whole bunch of other things.
Comment 30 Boris Zbarsky [:bz] (Out June 25-July 6) 2009-07-29 10:42:24 PDT
Comment on attachment 391176 [details] [diff] [review]
Fix

Should take this on branches.  This should be a very safe patch, in general: by design it only affects cases when stop() is called (or a new load is started, which always calls stop()) while an error page is loading or is showing.  In those cases, it makes sure to make the error page load look basically like a normal load that never completed until that point (which is what it really is, from the point of view of the rest of the system).
Comment 31 Samuel Sidler (old account; do not CC) 2009-07-29 11:58:33 PDT
Comment on attachment 391176 [details] [diff] [review]
Fix

Approved for 1.9.1.2 and 1.9.0.13. a=ss
Comment 32 Boris Zbarsky [:bz] (Out June 25-July 6) 2009-07-29 14:25:25 PDT
Pushed http://hg.mozilla.org/releases/mozilla-1.9.1/rev/a62f306d8fa7
Comment 33 Boris Zbarsky [:bz] (Out June 25-July 6) 2009-07-29 14:26:51 PDT
Checking in docshell/base/nsDocShell.cpp;
/cvsroot/mozilla/docshell/base/nsDocShell.cpp,v  <--  nsDocShell.cpp
new revision: 1.915; previous revision: 1.914
Comment 34 Alice0775 White 2009-07-30 10:37:39 PDT
The URL in the test case shows "https://bug451898.bugzilla.mozilla.org/attachment.cgi?id=335225" in the tab that is opened.
Is this right behavior?
I tried with new profile and the following hourly build
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090730 Minefield/3.6a1pre ID:20090730062258
Comment 35 :Gavin Sharp [email: gavin@gavinsharp.com] 2009-07-30 13:59:05 PDT
mozilla/docshell/base/nsDocShell.cpp 	1.914.4.1
Comment 36 Boris Zbarsky [:bz] (Out June 25-July 6) 2009-07-30 14:09:14 PDT
Alice, that's the right post-patch behavior, yes.
Comment 37 Henrik Skupin (:whimboo) 2009-07-31 01:41:54 PDT
Verified fixed on trunk and 1.9.1 with builds on all platforms like:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090730 Minefield/3.6a1pre (.NET CLR 3.5.30729) ID:20090730041801

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3pre) Gecko/20090730 Shiretoko/3.5.3pre (.NET CLR 3.5.30729) ID:20090730044055
Comment 38 juan becerra [:juanb] 2009-07-31 16:46:57 PDT
Verified on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.13) Gecko/2009073022 Firefox/3.0.13 (.NET CLR 3.5.30729)

Using test cases in comment #1 and comment #23. 3.0.11 opens a tab with a fake url. 3.0.13 shows the right url.
Comment 39 Smokey Ardisson (offline for a while; not following bugs - do not email) 2009-07-31 21:44:51 PDT
Boris, does this bug affect 1.8.1.x, too?  That is, is the bug the fake URL appearing in the location bar, the document.write()ing of arbitrary content in the content area, either, or both?  In my latest Camino builds off of 1.8.1.x, I see the fake URL in the location bar, but no document.write()-generated page content.
Comment 40 Boris Zbarsky [:bz] (Out June 25-July 6) 2009-07-31 22:21:05 PDT
The bug is the combination of the two.  I don't recall enough about the security model around about:blank in 1.8.1 to say anything useful about whether the behavior you see is reliable....

If you plan to release things off 1.8.1.x, I'd just backport this patch.
Comment 41 Martin Stránský 2009-08-20 01:20:14 PDT
Created attachment 395537 [details] [diff] [review]
1.8 version
Comment 42 Al Billings [:abillings] 2009-08-21 17:39:38 PDT
Verified for 1.9.0.14 using the two testcases (as in comment 38) and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.14pre) Gecko/2009081305 GranParadiso/3.0.14pre (.NET CLR 3.5.30729).
Comment 43 David Rios 2009-09-11 07:23:33 PDT
this bug is still present in the release version of firefox 3.5.3
Comment 44 Reed Loden [:reed] (use needinfo?) 2009-09-11 07:34:18 PDT
(In reply to comment #43)
> this bug is still present in the release version of firefox 3.5.3

Looks fixed to me on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3. Can you go to about: and post your build identifier here? What are you using as your testcase?
Comment 45 Honza Bambas (:mayhemer) 2009-10-13 07:46:13 PDT
Created attachment 406014 [details]
screen shot

This really doesn't seems to me fixed on 1.9.1.3 (Build identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)).

If the issue is that a fake page carries identity of the current ssl page, then using the test case does exactly that.
Comment 46 Boris Zbarsky [:bz] (Out June 25-July 6) 2009-10-13 08:05:12 PDT
> If the issue is that a fake page carries identity of the current ssl page

It's not.  The issue was that the fake page had SSL indicators and a URI of the current SSL page's choosing (NOT the URI of the current SSL page).
Comment 47 Boris Zbarsky [:bz] (Out June 25-July 6) 2009-10-13 08:05:48 PDT
And in particular, a page generated via document.write had better carry exactly the same SSL and identity indicators as the generating page.
Comment 48 Daniel Veditz [:dveditz] 2010-01-19 12:26:41 PST
Marking not blocking 1.8.1.next so we can ship a Thunderbird update, don't know if SeaMonkey 1.1.x or Camino still need this fix.
Comment 49 Robert Kaiser (not working on stability any more) 2010-01-19 12:55:33 PST
(In reply to comment #48)
> Marking not blocking 1.8.1.next so we can ship a Thunderbird update, don't know
> if SeaMonkey 1.1.x or Camino still need this fix.

If it affects SeaMonkey 1.1.18, we probably would like this in a 1.1.19 that we're planning to ship in sync with the Thunderbird update, but I'll make this SeaMonkey 1.1.19 a "ship what we can get" release that might ship with known vulnerabilities but be better than 1.1.18 at least. The only really secure path for SeaMonkey users is moving to 2.x in any case.
Comment 50 Smokey Ardisson (offline for a while; not following bugs - do not email) 2010-01-25 21:45:30 PST
It's unclear whether this affects Camino 1.6.x or not (see comment 39 and comment 40).  As I recall, the then-current 1.8.1.x behavior didn't match the then-current (pre-patched) 1.9.x behavior but the current 1.8.1.x behavior (I think the difference was the absence of generated content on the resulting page on 1.8.1.x), and certainly the current 1.8.1.x behavior doesn't match the current (patched) 1.9.x behavior.

Current 1.8.1.x behavior with Jesse's testcase in comment 1:

New window with title "test", http://www.google.com.ar%/ in the location bar, error page site icon, no SSL indicators, and no page content

Patched 1.8.1.x behavior (with patch in comment 41):

New window with title "test", https://bug451898.bugzilla.mozilla.org/attachment.cgi?id=335225 (aka the bug attachment) in the location bar, site icon for the bug attachment, SSL indicators to match the bug attachment, and no page content

This bug was nominated for 1.8.1.x-next, though, so clearly people do believe 1.8.1.x is vulnerable to something, and the patch improves things by clearing the bogus domain and site icon from the location bar (which seems like comment 47), so I'll second KaiRo; we'd also like to see this patch in the forthcoming 1.8.1.next for our Camino 1.6.11 release.

I'll be happy to land it, even, if everyone agrees the 1.8.1 patch does what it needs to do.

Note You need to log in before you can comment on or make changes to this bug.