266932 - (CVE-2005-4809) Invalid HTML (e.g. nested links) causes firefox to open different url than statusbar on new tab

Status: RESOLVED FIXED

(Firefox :: General, defect)

Description

[J. Carlos Navea]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20041001 Firefox/0.10.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20041001 Firefox/0.10.1

As reported by Netcraft
(http://news.netcraft.com/archives/2004/10/29/new_url_spoofing_flaw_found_in_internet_explorer.html),
this bug which affects IE, also affects Firefox.

The following 2 code samples cause firefox to display http://www.mozilla.org on
the statusbar but when you open the link in a new tab, it goes to google.com.

1)
<a href="http://www.mozilla.org"><table><tr><td><a
href="http://www.google.com/">http://www.mozilla.org</a></td></tr></table></a>

2)

<a href="http://www.mozilla.org"><div><a
href="http://www.google.com/">http://www.mozilla.org</a></div></a>



Reproducible: Always
Steps to Reproduce:
1. Right click on sample url, then choose open in new tab.
2.
3.

Actual Results:  
Instead of going to mozilla.org as reported by the status bar, it goes to google.com

Expected Results:  
Firefox should go to mozilla.org or report google.com on the status bar

Comment 1

[J. Carlos Navea]

Attachment: Testcase

Comment 2

[Bill Mason]

*** Bug 266943 has been marked as a duplicate of this bug. ***

Comment 3

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Note that this does not affect seamonkey.

Comment 4

[Jesse Ruderman]

*** Bug 266921 has been marked as a duplicate of this bug. ***

Comment 5

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

(In reply to comment #3)
> Note that this does not affect seamonkey.

Sorry, I wasn't reproducing it correctly.  It does affect Seamonkey.  Filed bug
266958.

Comment 6

[Phil Ringnalda (:philor)]

-> NEW

Comment 7

[Kenny Lee]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041029
Firefox/0.9.1+

happens on latest trunk of Firefox. 

Comment 8

[Ben Fowler]

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a5) Gecko/20041031
Firefox/0.9.1+

The Netcraft link quoted showed http://www.google.com/ in the status bar and 
took me to that URL.

The testcase had the faulty behaviour.

Comment 9

[Ryan Rubley]

http://slashdot.org/comments.pl?sid=127762&cid=10673350
Note you must add the extra </a> inside the table tag from the original exploit
shown at netcraft, in order to get the different tab-opening behaviour vs normal
opening behaviour.

Also, unless there is some way to fix <a href="http://www.mozilla.org/"
onclick="location.href='http://www.google.com/';
return false"> (separate bug of course) then this 'exploit' hardly matters.

Comment 10

[Jesse Ruderman]

As Ryan's code demonstrates, this bug is only relevant if you have JavaScript
enabled.  This bug should be fixed anyway, because JavaScript is usually
disabled in mail and because and a small percentage of users disable JavaScript
in the browser to be more secure.

Comment 11

[Ben Bucksch (:BenB)]

Bug reproducable in Mozilla 1.7 Linux (JS enabled and disabled), too.
-> Parser

Comment 12

[Bill Mason]

Making this a Seamonkey bug just dupes it to bug 266958.

Comment 13

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

(In reply to comment #12)
> Making this a Seamonkey bug just dupes it to bug 266958.

I filed the separate Seamonkey bug based on discussion in #developers (we
initially thought it was frontend code that would be different between the two
browsers).  If it is the same code, it would probably make more sense to dupe
that bug to this one.

Comment 14

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

(In reply to comment #12)
> Making this a Seamonkey bug just dupes it to bug 266958.

I filed the separate Seamonkey bug based on discussion in #developers (we
initially thought it was frontend code that would be different between the two
browsers).  If it is the same code, it would probably make more sense to dupe
that bug to this one.

Comment 15

[Boris Zbarsky [:bzbarsky]]

This bug is due to an interaction of front-end and back-end code.  In the end,
both may need fixing.  And since the frong-end code in Firefox is separate from
the SeaMonkey front-end code in this case, back to Firefox, marking dependent.

Comment 16

[Phil Ringnalda (:philor)]

*** Bug 267766 has been marked as a duplicate of this bug. ***

Comment 17

[Asa Dotzler [:asa]]

we ship with statusbar open to javascript manipulation by default. it's not to
be trusted. not going to block on this. 

Comment 18

[Nelson Menezes]

Is it a good idea to allow this through to 1.0? The strongest selling point of
FF for most people is security improvements over IE. This particular issue
received the usual hype in the media regarding Internet Explorer. Regardless of
the "critical/non-critical" importance of this bug, it is a security issue that
wouldn't ring well with the public: it would be bad publicity to let this sort
of thing through. I suggest it should be marked blocking again.

Comment 19

[Ryan Rubley]

I could have sworn that "Hide the status bar" and "Change status bar text" came
disabled by default in the advanced javascript options now.

Comment 20

[J. Carlos Navea]

Excuse my ignorance, I'm not seeing how having javascript on/off, or statusbar
javascript settings matter here. This bug affects the browser even if javascript
is turned off and/or even if statusbar javascript manipulation is disallowed.
The testcase code doesn't even have any javascript, does it some how trigger
some javascript issue?

Comment 21

[Ryan Rubley]

I think Asa was basically saying this bug is a moot point if javascript is
allowed to alter the status bar.  Although I thought the status bar altering
javascript was disabled by default, there are still other ways than this bug to
make the status bar misleading anyways, so I would agree with not blocking 1.0
for this.

Comment 22

[J. Carlos Navea]

Oh now I understand. Makes sense to me. Thank you.

Comment 23

[Blake Kaplan (:mrbkap) (inactive)]

*** Bug 274864 has been marked as a duplicate of this bug. ***

Comment 24

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050730
Firefox/1.0+

Comment 25

[Phil Ringnalda (:philor)]

Attachment: testcase

HTML testcase, since bug 90664 fixed the simplest case, so triggering it requires either XHTML or DOM manipulation now.

Comment 26

[Jesse Ruderman]

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051224 Firefox/1.5

With the newest testcase, I see "http://www.mozilla.org/" in the status bar before I click and "http://www.google.com/" in the status bar while the mouse button is down.  Left-clicking takes me to http://www.mozilla.org/, but Cmd+clicking takes me to http://www.google.com/ in a new tab.

Comment 27

[Daniel Veditz [:dveditz]]

A fix would be nice, but is this really a 1.5.0.1 blocker?

Comment 28

[Boris Zbarsky [:bzbarsky]]

I doubt there's a sane way to fix this for 1.5.0.1 anyway.

Comment 29

[Mike Connor [:mconnor]]

Attachment: workaround to match left-click behaviour and prevent spoofing (checked in on trunk)

I think this is an acceptable workaround, which near as I can tell matches the behaviour on left-click across the board in opening/displaying www.mozilla.org.  This patch would need to be undone if and when the core bug is addressed.

Comment 30

[[e-mail]]

(In reply to comment #28)
>I doubt there's a sane way to fix this for 1.5.0.1 anyway.
It probably depends on the event handling rewrite, but it might be possible to tweak the HandleDOMEventForAnchors process for 1.5.x

Comment 31

[Boris Zbarsky [:bzbarsky]]

I've tried two or three times.  Each time the net effect was links not working at all.  If someone else manages to do it, fine, but getting a branch-safe patch will be exciting.

Comment 32

[Daniel Veditz [:dveditz]]

Please get this reviewed and checked into the trunk ASAP if it's going to make any 1.8.0.1 train.

Comment 33

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Comment on attachment 207470 [details] [diff] [review]
workaround to match left-click behaviour and prevent spoofing (checked in on trunk)

r=vladimir

Comment 34

[[e-mail]]

Attachment: HTML anchor processing fix

This seems to work for me, but I haven't found where XLinks are handled yet.

Comment 35

[Mike Connor [:mconnor]]

Comment on attachment 207470 [details] [diff] [review]
workaround to match left-click behaviour and prevent spoofing (checked in on trunk)

landed on trunk, given bz's comments I think we want to take this for 1.5.0.1 instead of the better fix.

Comment 36

[Boris Zbarsky [:bzbarsky]]

XLinks are handled in nsXMLElement.cpp

Comment 37

[[e-mail]]

Comment on attachment 207507 [details] [diff] [review]
HTML anchor processing fix

This isn't quite right, some (but not all) of the events need to be handled in the system event group so that normal JS bubbling listeners will fire first!

Comment 38

[Daniel Veditz [:dveditz]]

Comment on attachment 207470 [details] [diff] [review]
workaround to match left-click behaviour and prevent spoofing (checked in on trunk)

not enough baking for 1.8.0.1, very minor spoofing issue

Comment 39

[Matt]

Since it's fixed now, will the bug be closed?  WFM in 20060116(04).

Comment 40

[Boris Zbarsky [:bzbarsky]]

If this bug is closed, please file a new bug to fix the UI once bug 234455 (or bug 127903, or bug 62151, etc) is fixed.

Comment 41

[Mike Connor [:mconnor]]

filed bug 325652 on undoing this change

Comment 42

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 207470 [details] [diff] [review]
workaround to match left-click behaviour and prevent spoofing (checked in on trunk)

requesting 1.8 branch approval for this (with bug 324946's patch)

Comment 43

[:Gavin Sharp [email: [e-mail]]]

mozilla/browser/base/content/browser.js; new revision: 1.479.2.70;