Last Comment Bug 249322 - multiline urls in address bar allow spoofing
: multiline urls in address bar allow spoofing
[have patch][reporter-external]
: csectype-spoof, fixed-aviary1.0, fixed1.7.5
Product: Core
Classification: Components
Component: Security (show other bugs)
: Trunk
: x86 Linux
-- normal (vote)
: ---
Assigned To: Daniel Veditz [:dveditz]
: benc
: David Keeler [:keeler] (use needinfo?)
: 260932 265580 (view as bug list)
Depends on: 77932
Blocks: 248511 368263
  Show dependency treegraph
Reported: 2004-06-30 19:08 PDT by Jesse Ruderman
Modified: 2013-06-10 02:01 PDT (History)
13 users (show)
asa: blocking1.7.5+
chofmann: blocking‑aviary1.0+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

pref switch (not preferred) (672 bytes, patch)
2004-10-22 12:56 PDT, Daniel Veditz [:dveditz]
no flags Details | Diff | Splinter Review
browser code patch (preferred) (2.23 KB, patch)
2004-10-22 13:04 PDT, Daniel Veditz [:dveditz]
jst: review+
bryner: superreview+
asa: approval‑aviary+
Details | Diff | Splinter Review

Description User image Jesse Ruderman 2004-06-30 19:08:16 PDT reported this bug to  It's a known bug
(bug 77932), but 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

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

URL Obfuscation possible when multiline URL pasted into Firefox address Bar.

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.

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.

- --
- --

A screenshot is available at

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).
Comment 1 User image Daniel Veditz [:dveditz] 2004-09-22 16:06:09 PDT
*** Bug 260932 has been marked as a duplicate of this bug. ***
Comment 2 User image Ben Bucksch (:BenB) 2004-09-27 23:39:45 PDT
Dup of bug 23485?
Comment 3 User image chris hofmann 2004-09-28 19:44:32 PDT
be good if we could get this for 1.0.  anyone have ideas on a patch?
Comment 4 User image Ben Bucksch (:BenB) 2004-10-22 06:14:32 PDT
*** Bug 265580 has been marked as a duplicate of this bug. ***
Comment 5 User image Asa Dotzler [:asa] 2004-10-22 12:31:35 PDT
Let's flip this pref and get it landed. Time is short. 
Comment 6 User image Daniel Veditz [:dveditz] 2004-10-22 12:56:59 PDT
Created attachment 163054 [details] [diff] [review]
pref switch (not preferred)

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\%20%20%20%20%20%20\, which I suspect would
be nearly as effective in practice.
Comment 7 User image Daniel Veditz [:dveditz] 2004-10-22 13:04:21 PDT
Created attachment 163059 [details] [diff] [review]
browser code patch (preferred)

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 :-)

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 8 User image Christian :Biesinger (don't email me, ping me on IRC) 2004-10-22 13:46:16 PDT
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 9 User image Johnny Stenback (:jst, 2004-10-22 14:23:02 PDT
Comment on attachment 163059 [details] [diff] [review]
browser code patch (preferred)


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 10 User image Brian Ryner (not reading) 2004-10-22 14:51:27 PDT
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
Comment 11 User image Asa Dotzler [:asa] 2004-10-22 14:52:58 PDT
Comment on attachment 163059 [details] [diff] [review]
browser code patch (preferred)

a=asa for aviary checkin
Comment 12 User image 2004-10-22 15:40:31 PDT
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 ;-)
Comment 13 User image Daniel Veditz [:dveditz] 2004-10-22 17:34:43 PDT
Fixed on aviary and 1.7 branches
Comment 14 User image Daniel Veditz [:dveditz] 2004-10-22 17:43:38 PDT
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?
Comment 15 User image Daniel Veditz [:dveditz] 2004-10-24 02:49:04 PDT
Fixed on trunk

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