Closed Bug 278418 Opened 20 years ago Closed 12 years ago

location bar spoofing when downloading with "onunload"

Categories

(Core :: Security, defect)

Product:
Core
Component:
Security
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox-esr17 --- unaffected
b2g18 --- unaffected
b2g18-v1.0.0 --- unaffected

People

(Reporter: u115577, Unassigned)

References

Details

(Keywords: sec-low, Whiteboard: [sg:low spoof])

User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a6) Gecko/20050105 Firefox/1.0+ When downloading invoked with "onunload", download dialog appears, then browser's location bar change to URL of linked page. Users may look at location bar instead of URL in the dialog, confirm that it is reliable site, click OK, and download malicious file. Testcase http://beta51.minutedesign.com/download.html Reproducible: Always Steps to Reproduce: 1. Click the link in testcase 2. Take me to ftp.mozilla.org 3. Download dialog appears 4. See location bar of browser -- 5. Click OK to download malicious file Actual Results: URL in location bar is http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/1.0/win32/en-US/ Expected Results: URL in location bar should be http://beta51.minutedesign.com/download.html or http://beta51.minutedesign.com/Firefox Setup 1.0.exe Source of testcase: <html><head><title>Testcase</title></head> <body onunload="location.href = 'Firefox%20Setup%201.0.exe';"> <a href="http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/1.0/win32/en-US/">Download Firefox 1.0</a> (faked) </body></html>
Testcase 2: http://beta51.minutedesign.com/download-2.html Location bar will be highlighted as secure site. More effective to let users to download.
Confirming... Not sure we could change this quickly
Blocks: sg-ff101, sg-moz176
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.7.6?
Flags: blocking-aviary1.1?
Whiteboard: [sg:fix]
Flags: blocking-aviary1.1? → blocking-aviary1.1+
Flags: blocking-aviary1.0.1?
Assignee: dveditz → roc
Flags: blocking1.7.6?
Flags: blocking1.7.6+
Flags: blocking-aviary1.0.1?
Flags: blocking-aviary1.0.1+
What's happening here is that nsDocShell::CreateContentViewer fires the 'unload' event and then calls OnLoadingSite which eventually fires the onLocationChange event with the new URI. Problem is, if the 'unload' event changes the location, the location gets set correctly but then on return to the outer CreateContentViewer, OnLoadingSite still gets called with the old target location, overwriting the new (true) location. I think CreateContentViewer needs to detect that 'unload' triggered a load to override this one and bail out without doing OnLoadingSite.
Disregard the last comment, it's wrong. I'm not really sure what to do here. There's nothing wrong with our code as designed. Suppose that the testcase pointed you to a non-bogus page. You click on the link, it navigates to a new page and the download box pops up with the download requested by the old page. The download box does give the correct location of the resource to be downloaded. So tell me what *should* be happening from the user's point of view. Forgetting about onload for a minute, what if the page just opened a new window pointing to a page in the trusted domain and then later (on a timer) triggers a download? Are we supposed to block that too? I don't think so. I think the user needs to read the resource location in the download box and there is no way to prevent the location bars of various windows from saying other things. I'm leaning towards WONTFIXING this bug. If we do want to do something about it, then maybe we should dim the URLbars of non-focused windows.
The targets in both testcases are real pages with real content, what do you mean by "non-bogus pages"? In some ways the second case overlaps with the lock icon bugs Darin is looking at--we're flipping the security state upon contacting the site despite the fact that the load was cancelled by the onunload. When I pointed the download .exe at a non-existant file I could see that the security state flipped first, I then got an alert about the .exe not found, *then* the urlbar changed to addons.mozilla.org even though the load had already been cancelled. flipping back to "nominated" so this bug can come up again for discussion.
Flags: blocking1.7.6?
Flags: blocking1.7.6+
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.1+
Flags: blocking-aviary1.0.1?
Flags: blocking-aviary1.0.1+
Firefox features "location bar highlighting" on secure site. Advanced users (include me) may notice the domain appeared in the download dialog is different from location bar, but common end users have complete confidence in highlighting. Without highlighting, location bar is more visible than URL in download dialog anyway. I think this bug brings potential risk to end users. Location bar (URL, favicon, lock icon and hilighting) should not change when "onunload" event prevents linked page from loading.
minus for the branches, it's not clear what to do or if we really need to do anything. Leaving nominated for 1.1 so we don't drop the ball entirely, but there's no fix to rush into the upcoming security releases.
Flags: blocking1.7.6?
Flags: blocking1.7.6-
Flags: blocking-aviary1.0.1?
Flags: blocking-aviary1.0.1-
Okay, we should fix things so we don't flip security state if onunload cancelled the load. But that actually won't help this bug at all. The attacker could produce exactly the same effect by doing what I said in comment #4: first load "https://bugzilla.mozilla.org" into a new window, and use a timer to later initiate a download from another window. The download dialog will pop up on top of https://bugzilla.mozilla.org. If you think that must be prevented, then we need a completely different solution.
transferring nomination to 1.8b4. If we don't get it there, we don't get it for 1.1.
Flags: blocking-aviary1.1? → blocking1.8b4?
Looks like this isn't going to make it for beta.
Flags: blocking1.8b4? → blocking1.8b4-
Whiteboard: [sg:fix] → [sg:spoof]
Flags: testcase+
Whiteboard: [sg:spoof] → [sg:low spoof]
Flags: in-testsuite+ → in-testsuite?
This was fixed by disallowing navigation during unload in bug 371360.
Status: NEW → RESOLVED
Closed: 12 years ago
Depends on: CVE-2007-1095
Resolution: --- → FIXED
Group: core-security
You need to log in before you can comment on or make changes to this bug.