Bug 266932 (CVE-2005-4809)

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

RESOLVED FIXED in Firefox 2 alpha1

Status

()

--
major
RESOLVED FIXED
14 years ago
8 years ago

People

(Reporter: loconet, Assigned: mconnor)

Tracking

(Blocks: 1 bug, {fixed1.8.1})

2.0 Branch
Firefox 2 alpha1
fixed1.8.1
Points:
---
Dependency tree / graph
Bug Flags:
blocking-aviary1.0 -
blocking1.8.0.1 -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:low] link spoofing in mail / webmail)

Attachments

(2 attachments, 2 obsolete attachments)

(Reporter)

Description

14 years ago
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
(Reporter)

Comment 1

14 years ago
Created attachment 164020 [details]
Testcase

Comment 2

14 years ago
*** Bug 266943 has been marked as a duplicate of this bug. ***
Note that this does not affect seamonkey.

Updated

14 years ago
Flags: blocking-aviary1.0?

Comment 4

14 years ago
*** Bug 266921 has been marked as a duplicate of this bug. ***
(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.
-> NEW
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 7

14 years ago
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

14 years ago
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

14 years ago
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

14 years ago
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

14 years ago
Bug reproducable in Mozilla 1.7 Linux (JS enabled and disabled), too.
-> Parser
Component: General → Layout
OS: Windows 2000 → All
Product: Firefox → Browser
Hardware: PC → All
Version: unspecified → Trunk

Updated

14 years ago
Assignee: firefox → nobody
QA Contact: firefox.general → core.layout

Comment 12

14 years ago
Making this a Seamonkey bug just dupes it to bug 266958.
(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.
(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.
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.
Assignee: nobody → firefox
Component: Layout → General
Depends on: 266958
Product: Browser → Firefox
QA Contact: core.layout → firefox.general
*** Bug 267766 has been marked as a duplicate of this bug. ***

Comment 17

14 years ago
we ship with statusbar open to javascript manipulation by default. it's not to
be trusted. not going to block on this. 
Flags: blocking-aviary1.0? → blocking-aviary1.0-

Comment 18

14 years ago
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

14 years ago
I could have sworn that "Hide the status bar" and "Change status bar text" came
disabled by default in the advanced javascript options now.
(Reporter)

Comment 20

14 years ago
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

14 years ago
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.
(Reporter)

Comment 22

14 years ago
Oh now I understand. Makes sense to me. Thank you.
*** Bug 274864 has been marked as a duplicate of this bug. ***
WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050730
Firefox/1.0+
Created attachment 206815 [details]
testcase

XHTML testcase, since bug 90664 fixed the simplest case, so triggering it requires either XHTML or DOM manipulation now.
Attachment #164020 - Attachment is obsolete: true
Assignee: firefox → nobody

Comment 26

13 years ago
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.
Flags: blocking1.8.0.1?
Whiteboard: [sg:low] link spoofing in mail / webmail
A fix would be nice, but is this really a 1.5.0.1 blocker?
Assignee: nobody → mconnor
I doubt there's a sane way to fix this for 1.5.0.1 anyway.
(Assignee)

Comment 29

13 years ago
Created attachment 207470 [details] [diff] [review]
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.
Attachment #207470 - Flags: review?(vladimir)

Comment 30

13 years ago
(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
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.
Please get this reviewed and checked into the trunk ASAP if it's going to make any 1.8.0.1 train.
Flags: blocking1.8.1?
Comment on attachment 207470 [details] [diff] [review]
workaround to match left-click behaviour and prevent spoofing (checked in on trunk)

r=vladimir
Attachment #207470 - Flags: review?(vladimir) → review+

Comment 34

13 years ago
Created attachment 207507 [details] [diff] [review]
HTML anchor processing fix

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

Comment 35

13 years ago
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.
Attachment #207470 - Attachment description: workaround to match left-click behaviour and prevent spoofing → workaround to match left-click behaviour and prevent spoofing (checked in on trunk)
Attachment #207470 - Flags: approval1.8.0.1?
XLinks are handled in nsXMLElement.cpp

Comment 37

13 years ago
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!
Attachment #207507 - Attachment is obsolete: true
Flags: blocking1.8.0.1? → blocking1.8.0.1-
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
Attachment #207470 - Flags: approval1.8.0.1? → approval1.8.0.1-

Comment 39

13 years ago
Since it's fixed now, will the bug be closed?  WFM in 20060116(04).
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.

Updated

13 years ago
Summary: Invalid HTML causes firefox to open different url than statusbar on new tab → Invalid HTML (e.g. nested links) causes firefox to open different url than statusbar on new tab

Updated

13 years ago
Blocks: 307087

Updated

13 years ago
Blocks: 325274
(Assignee)

Comment 41

13 years ago
filed bug 325652 on undoing this change
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
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)
Attachment #207470 - Flags: approval-branch-1.8.1?(mconnor)
(Assignee)

Updated

13 years ago
Attachment #207470 - Flags: approval-branch-1.8.1?(mconnor) → approval-branch-1.8.1+
mozilla/browser/base/content/browser.js; new revision: 1.479.2.70;
Keywords: fixed1.8.1
Target Milestone: --- → Firefox 2 alpha1
Version: Trunk → 2.0 Branch
Alias: CVE-2005-4809
Duplicate of this bug: 390630
You need to log in before you can comment on or make changes to this bug.