noys@bigpond.com reported this bug to security@mozilla.org. It's a known bug (bug 77932), but noys@bigpond.com was the first to identify it as a security hole and provide an exploit. The rest of this bug report is pasted from the e-mail from noys@bigpond.com. Versions effected: ================== Confirmed in: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040615 Firefox/0.9 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8 Thought to be vulnerable: Other versions of Mozilla on Linux Summary: ======== URL Obfuscation possible when multiline URL pasted into Firefox address Bar. Details: ======== When a multiline URL is pasted into the address bar, the whole URL is evaluated and loaded by Firefox, but only the first line of the URL is displayed in the address line. I have verified this bug in Firefox 0.8 and 0.9 on Linux. Reproducibility: ================ Every time Steps to Reproduce: =================== 1. Type a multiline URL into a text editor 2. Copy the URL into the clipboard 3. Paste the URL into the address bar, and press enter. Actual Results: =============== The URL is loaded in it'e entirety, but anything after the first pasted newline is not displayed. Expected Results: ================= The Software should either drop anything after the first newline, or strip newline characters out of the URL, and display the whole lone URL. Additional Information: ======================== - - The additional lines of the pasted URL remain hidden in the address bar when you click in it, and type a new URL. - - This issue has implications in phishing scams as obfuscation of the real hostname is possible when used in conjuction with a malicious site that utilises wildcard DNS configurations (e-gold is just an example of a DNS domain that was used in Jelmer's recent COELOCANTH experiments with MSIE. See Bugtraq for more information). To test, paste the URL inbetween the -- characters into the address bar in firefox on Linux. - -- http://www.google.com \www.e-gold.com/ - -- A screenshot is available at http://users.bigpond.com/blurred.vision/firefox3.png. Severity: ========= Allows obfuscation of the real hostname being accessed. Phishing scam friendly. Injection most likely possible if newline chars are URL encoded in a standard HTTP link (untested).

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

Dup of bug 23485?

be good if we could get this for 1.0. anyone have ideas on a patch?

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

Let's flip this pref and get it landed. Time is short.

Here's the simple pref switch to make unix behave like Mac and Windows. I'm reluctant to go this way because there's a small contingent that vociferously wants Unix to be different, with a long history of multiple bugs and alternate solutions. But it does stop the spoofing, at least to the extent that people think the version described in this bug was worse than http://www.google.com\%20%20%20%20%20%20\www.e-gold.com/, which I suspect would be nearly as effective in practice.

This lets the unix-y pasteNewLines pref setting do what it was intended to, and fixes the URL bar. In *intent* the existing code was already doing the right thing. But there was a strange little chunk of code in nsTextControlFrame::SetValue() that would drop attempts to set the value of a text control if the new value was the same as the old minus new-line characters. It seems special crafted to purposefully block what we were trying to do :-) http://lxr.mozilla.org/mozilla/source/layout/html/forms/src/nsTextControlFrame.cpp#3063 ripping out that if-block worked, but modifications in that area cited obscure text area bugs that I worried about regressing, and the current form was apparently checked in with a massive form control update so it's very hard to say what that specific check was for. Seemed much safer to fix it in the browser code for just the URL bar.

Comment on attachment 163059 [details] [diff] [review] browser code patch (preferred) I'm not a super-reviewer... I suggest asking neil for srs to xpfe code

Comment on attachment 163059 [details] [diff] [review] browser code patch (preferred) r=jst. Ideally we'd be able to strip out newlines on paste, but that seems hard, and I don't think that we've got the time to do that now...

Comment on attachment 163059 [details] [diff] [review] browser code patch (preferred) Looks ok. I'd prefer a slightly more descriptive comment about what situation would cause .value to not be the value we just set it to, but if that comment would expose this vulnerability too much before we're ready, don't worry about it.

Comment on attachment 163059 [details] [diff] [review] browser code patch (preferred) a=asa for aviary checkin

Comment on attachment 163059 [details] [diff] [review] browser code patch (preferred) > this.urlBar.value = location; >+ if (this.urlBar.value != location) { >+ this.urlBar.value = ""; // hack for bug 249322 >+ this.urlBar.value = location; >+ } I'm not quite sure what the point of the first, second and fifth lines are. Just clearing the value before setting it to the location should work, no? BTW, there's an outstanding enhancement requested that typing whitespace (which would include newlines) would automatically trigger an internet search, which was why I was having so much trouble reproducing this bug ;-)

Fixed on aviary and 1.7 branches

I guess I was thinking my additions are a hack to work around a problem that might someday go away. The original code would do the right thing if not for the mysterious secret behavior down in the textContextFrame. I think you're right, I'll just do urlBar.value = ""; urlBar.value = location; for all page changes on the trunk. Want me to do that branch that way too?

Fixed on trunk