multiline urls in address bar allow spoofing




13 years ago
4 years ago


(Reporter: Jesse Ruderman, Assigned: dveditz)


({csectype-spoof, fixed-aviary1.0, fixed1.7.5})

csectype-spoof, fixed-aviary1.0, fixed1.7.5
Dependency tree / graph
Bug Flags:
blocking1.7.5 +
blocking-aviary1.0 +

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [have patch][reporter-external] )


(2 attachments)



13 years ago 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).


13 years ago
Flags: blocking1.8a2?


13 years ago
Flags: blocking1.8a2? → blocking1.8a2+


13 years ago
Flags: blocking1.7.1?


13 years ago
Flags: blocking-aviary1.0?
*** Bug 260932 has been marked as a duplicate of this bug. ***

Comment 2

13 years ago
Dup of bug 23485?

Comment 3

13 years ago
be good if we could get this for 1.0.  anyone have ideas on a patch?
Flags: blocking-aviary1.0? → blocking-aviary1.0+


13 years ago
Flags: blocking1.8a2+
Flags: blocking1.7.x?
Flags: blocking1.7.x+

Comment 4

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

Comment 5

13 years ago
Let's flip this pref and get it landed. Time is short. 
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.
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.
Whiteboard: [have patch]
Attachment #163059 - Flags: superreview?(cbiesinger)
Attachment #163059 - Flags: review?(jst)
Whiteboard: [have patch] → [have patch] need reviews
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
Attachment #163059 - Flags: superreview?(cbiesinger) → superreview?(
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...
Attachment #163059 - Flags: review?(jst) → review+
Whiteboard: [have patch] need reviews → [have patch] need sr=, a=
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
Attachment #163059 - Flags: superreview?( → superreview+

Comment 11

13 years ago
Comment on attachment 163059 [details] [diff] [review]
browser code patch (preferred)

a=asa for aviary checkin
Attachment #163059 - Flags: approval-aviary+


13 years ago
Whiteboard: [have patch] need sr=, a= → [have patch] ready to land

Comment 12

13 years ago
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
Keywords: fixed-aviary1.0, fixed1.7.x
Whiteboard: [have patch] ready to land → [have patch] need trunk landing
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
Last Resolved: 13 years ago
Resolution: --- → FIXED


13 years ago
QA Contact: benc
Whiteboard: [have patch] need trunk landing → [have patch]


13 years ago
Blocks: 248511
Group: security


11 years ago
Blocks: 368263


4 years ago
Keywords: csec-spoof
Whiteboard: [have patch] → [have patch][reporter-external]
You need to log in before you can comment on or make changes to this bug.