Closed Bug 246804 Opened 20 years ago Closed 17 years ago

[Win32/MacOSX only] Status bar link destination spoofing with invalid HOST header containing %2F (SA11856?)

Categories

(Core :: Security, defect)

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

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: ostgote, Assigned: dveditz)

References

(Depends on 1 open bug,
URL
)

Details

(Keywords: fixed1.8, Whiteboard: [sg:low spoof] Split into bug 304904 and bug 304905) 

User-Agent:       Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.8a2) Gecko/20040613 Netscape/7.1
Build Identifier: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.8a2) Gecko/20040613

For details see URL above and this
http://seclists.org/lists/bugtraq/2004/Jun/0170.html.

I hope this bug is not a duplicate, I couldn't find an existing public bug.


Reproducible: Always
Steps to Reproduce:
1. Try to open
http://www.heise.de%2f%20%20%20%20%20%20%20%20%20%20%20redir=.e-gold.com/

Actual Results:  
you will go to e-gold.com

Expected Results:  
Don't go anywhere or warn that you will go to e-gold.com instead of heise.de.
I can't reproduce it :
”www.heise.de%2f%20%20%20%20%20%20%20%20%20%20%20redir=.e-gold.com could not be
found. Please check the name and try again.“

Neither with a Fx nightly (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a2)
Gecko/20040614 Firefox/0.8.0+),
nor with Moz1.7RC3 (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040608)
(In reply to comment #1)
> I can't reproduce it :

Do you use a proxy? With most proxies it doesn't work.


I can not reproduce it too with
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040613
Firefox 0.8 unter Linux (from Debian/unstable)

I'm not using a proxy. Xanthor from comment #1 also don't use a proxy, because
the messeage comes from Mozilla. Otherwise there would be a html-site generated
by the proxy-server.
hm... maybe the dns service should check whether the hostnames it gets are
syntactically valid and fail if they aren't...


...as our error handling is in the state it is, it may take some work to get
that to show a correct error message, though.
confirming
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040614 Firefox/0.9
Confirmed on Mac OS X 10.2.8 (without a proxy)

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a2) Gecko/20040614
Status: UNCONFIRMED → NEW
Ever confirmed: true
I cannot reproduce this bug in:

  Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040603 Firefox/0.8.0+

Reporter: can you please provide a HTTP log of the URL load.  please see the
instructions here for generating a HTTP log:

  http://www.mozilla.org/projects/netlib/http/http-debugging.html

Please submit the log file as an attachment to this bug report.  Thanks!
I can reproduce the problem as stated in this bug. The status bar shows
"heise.de/" (but for most victims it's trivial to spoof the status bar with
javascript), but I go to the full host <garbage>e-gold.com.

I don't see how this is any different than most phishing spoofed hosts. If it's
not this it's http://www.heise.de:supportblahblahblah@e-gold.com, right?

(I'm using 1.7rc2 at the moment in case it matters).

This is quite different than Thor Larholm's message which says IE will put
heise.de/ in the address bar *and* (worse) apparently use that as the security
zone. Here I see a perfectly legal (albeit ugly and misleading) host in the url bar.
In 1.7rc3 I get redirected. Also, using the URL
http://seclists.org%2Fredir=.e-gold.com/ I get redirected

using http://seclists.org/redir=.e-gold.com/ I do not get redirected

It seems the %2F conversion has an effect
(In reply to comment #2)
> 
> Do you use a proxy? With most proxies it doesn't work.
> 
No : no proxy.
I've tested again with another computer with linux (and again no proxy), and I
still can't reproduce it with Fx 0.8

But, I've tested an a windows' computer (I don't know what version) with Fx 0.8,
and the bug occures.
So maybe it's a win32/OSX-only bug ?
Whiteboard: [sg:needinfo]
Hmm.. I can also repro this on Windows but not Linux.  Hmm.. that is very
interesting.

I tested Firefox 0.9 on Win2k.
Yeah, it seems to Win/Mac only, changed summary. Tested with current trunk
builds and FF 0.9 (for me it works with a proxy).

The following URLs work:

http://[trusted_site]%2F[optional%20][.][malicious_site]/
The "%2f%" instead of a "/" after trusted_site is mandatory. The "." is only
necessary if malicious_site is a SLD like e-gold.com. If you use a subdomain
like www, you must omit the dot. The %20 are only for spoofing.

working examples:
http://www.microsoft.com%2fwww.e-gold.com/
http://www.microsoft.com%2f.e-gold.com/

not working examples:
http://www.microsoft.com%2fe-gold.com/
http://www.microsoft.com%2f.www.e-gold.com/
http://www.microsoft.com/www.e-gold.com/

Note: Successful exploitation requires that a malicious web site's domain
supports wildcard DNS and accepts invalid values in the "Host:" header.

(In reply to comment #8)
> I don't see how this is any different than most phishing spoofed hosts. If it's
> not this it's http://www.heise.de:supportblahblahblah@e-gold.com, right?
Right, it is only a kind of spoofed host. URL bar shows the full link URL
encoded like "http://www.ebay.com%2f%20%20%20%20%20%20%20%20.example.com/" and
the status bar shows the unescaped "http://www.ebay.com/        .example.com/".

> This is quite different than Thor Larholm's message which says IE will put
> heise.de/ in the address bar *and* (worse) apparently use that as the security
> zone. 
Because Mozilla has no security zones, it can't do anything wrong. :-) That's
the reason why the IE bug (see http://secunia.com/advisories/11830/) is rated
"moderately critical" (impact:	security bypass, spoofing) and for Mozilla only
"less critical" (impact: spoofing).
Summary: Address Bar Spoofing Weakness (Secunia Advisory SA11856) - %2F %20 trick, invalid HOST header → [Win32/MacOSX only] Address Bar Spoofing Weakness (Secunia Advisory SA11856) - %2F %20 trick
sorry, summary was changed too much

HTTP log extract:

0[771de0]: nsHttpAuthCache::GetAuthEntryForPath
[key=http://wwwproxy-ffm-vpn.adm.arcor.net:8000 path=(null)]
0[771de0]: nsHttpAuthCache::GetAuthEntryForPath
[key=http://www.microsoft.com%2f.e-gold.com:80 path=/]
0[771de0]: nsHttpChannel::SetupTransaction [this=25fcd80]
0[771de0]: Creating nsHttpTransaction @2601550
0[771de0]: nsHttpTransaction::Init [this=2601550 caps=1]
0[771de0]: http request [
0[771de0]:   GET http://www.microsoft.com%2f.e-gold.com/ HTTP/1.1
0[771de0]:   Host: www.microsoft.com%2f.e-gold.com
0[771de0]:   User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.8a2)
Gecko/20040615 Netscape/7.1
0[771de0]:   Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
0[771de0]:   Accept-Language: de,en;q=0.5
0[771de0]:   Accept-Encoding: gzip,deflate
0[771de0]:   Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
0[771de0]:   Keep-Alive: 300
0[771de0]:   Proxy-Connection: keep-alive
0[771de0]: ]

Hmm ... a "%f" before the first path symbol "/" after the domain should be easy
to find for the parser.

(In reply to comment #4)
> hm... maybe the dns service should check whether the hostnames it gets are
> syntactically valid and fail if they aren't...
see Bug 140379
Summary: [Win32/MacOSX only] Address Bar Spoofing Weakness (Secunia Advisory SA11856) - %2F %20 trick → [Win32/MacOSX only] Address Bar Spoofing Weakness (Secunia Advisory SA11856) - %2F %20 trick, invalid HOST header
Setting NSPR_LOG_MODULES=nsHostResolver:5 under Win2k reveals that Mozilla is
passing the string:
 
  www.heise.de%2f%20%20%20%20%20%20%20%20%20%20%20redir=.e-gold.com

to the Win32 gethostbyname function.  And, surprisingly the OS is able to
resolve that string to 63.240.230.10.  The OS should refuse to resolve this URL
string!

Given how loose the Win32 resolver is, I think we should protect our users by
ensuring that we reject any hostname that contains illegal characters, like '%'

This is apparently what GLIBC's resolver does, which explains why the hostname
does not resolve under Linux.
Hmm.. actually, it appears that the Win32 resolver is simply passing the request
on to the e-gold.com nameserver.  The e-gold.com nameserver is happy to map
{anything}.e-gold.com to the IP address 63.240.230.10 even though {anything}
might contain invalid characters per the DNS specification.  Interesting...

Other domain name servers like .cnn.com do not have this problem.  However,
since .e-gold.com in this example represents the domain of the attacker, there's
no point expecting that .e-gold.com will reject bad characters! ;-)

It seems like the proper solution here is for us to block hostnames that contain
invalid characters.  However,

  www.heise.de-----------------------------------------------------x.e-gold.com

works just as well.  The %-escaping is really not needed to cause this problem.
And moreover this string, which is a valid DNS name, causes the problem to
appear on Linux as well as Windows and OSX.  We would not be able to recognize
this as an invalid hostname.

What to do then?
The point of the %2f escape was twofold:
 - In the status bar it shows as a '/', furthering the spoof
 - On IE it shows '/' in the Address bar(!) and changes the
   interpretation of the security zone (!!!)

I don't think following the link is the problem, it's the status bar not showing
the real host we're going to use, invalid chars and all.

Didn't we fix basically this problem with %00 and %01 leading to status bar
spoofs? Why can't we do the same for all non-alphanumeric escapes in a host name.
Yeah, UnescapeForUI is broken.  We should never unescape %-escaped chars that
appear in the hostname.  Fixing that should help.
However, it appears that nsTextToSubURI::UnEscapeURIForUI does not have any
context about which URI fragment the parameter |aURIFragment| refers.  So, it
cannot selectively unescape based on the field; however, we did add code to make
it not unescape control characters.  Perhaps we could just do the same for %2F
since that can change the way the URL string is interpreted.  Is that what you
are thinking we should do?  Does that sound like a sufficient plan to you?
I don't see this as a real solution, especially since darin pointed out that
spoofing is possible without using %2F, although it looks more convincing with.
I would not single out %2F anyway, why not display the statusbar url completely
unchanged? We loose a little bit readability in the status bar, but it's a bad
world out there.

There was some discussion in bug #122445 and its related bugs about a color
scheme in the status bar to mark the hostname or a separate host field in the
status bar. I see that as a possible solution, maybe a combination of both with
not unescaping the url for status bar display.
The problem with very long hostnames are discussed in other bugs.

I would propose the following:
a) implement something like Bug 140379 (including warning dialog) or
b) don't unescape any escaped chars from a hostname in status bar.

a) is much better but not easy to implement I guess. 
Is www.heise.de                                                   x.e-gold.com
a valid host name? (note that those are meant to be &#160;s above, not spaces)
As for the unescaping I already asked for it only to be done for non-ascii
characters and got ignored. And try and avoid dialogs, please.
Or how about / (U+FF0F, hopefully)? Seems to be valid IDN here.
confirmed 2005-02-07 in Camino 082
It looks like this bug has been NEW for half a year now. Could we get it fixed
instead of continuing to discuss it?

http://secunia.com/multiple_browsers_idn_spoofing_test

Secunia Advisory:	SA14163	Print Advisory  
Release Date:	2005-02-07

Critical:	
Moderately critical
Impact:	Spoofing
Where:	From remote
Solution Status:	Unpatched

Software:	Mozilla 1.7.x
Mozilla Firefox 0.x
Mozilla Firefox 1.x

	Select a product and view a complete list of all Patched/Unpatched Secunia
advisories affecting it.

Description:
Eric Johanson has reported a security issue in Mozilla / Firefox / Camino, which
can be exploited by a malicious web site to spoof the URL displayed in the
address bar, SSL certificate, and status bar.
(In reply to comment #23)
> http://secunia.com/multiple_browsers_idn_spoofing_test
> 
> Secunia Advisory:	SA14163	Print Advisory  

That is bug 279099, please don't mix different issues.
I wonder why Secunia now claims this is fixed in Mozilla 1.7.2. Spoofing still
works with 1.8b2 builds.

Solution:
Mozilla 1.7.2 is not affected by this vulnerability.
Changelog:
2004-08-20: Added Mozilla 1.7.2 in "Solution" section.
Flags: blocking1.8b4?
The impact of this security hole is that content can spoof link URLs shown in
the status bar without being able to change link URL onclick or screw with the
status bar directly.  This is the case in Thunderbird, where JavaScript is
disabled by default.  Checking the destinations of links in mail messages is the
only reliable way to avoid phishing scams, so this bug needs to be fixed in at
least one of Thunderbird or Firefox, preferably both.

I think the best fix is to do both of these:

1. Fix UnescapeForUI to not unescape %-escaped chars in the hostname, as
suggested in comment 17.  This will make Thunderbird secure even when used with
a browser without fix (2).

2. Refuse to look up invalid hostnames, as suggested in comment 14.  This will
make Firefox consistent across platforms and will make Firefox secure even when
used with a mail client or webmail site without fix (1).
Summary: [Win32/MacOSX only] Address Bar Spoofing Weakness (Secunia Advisory SA11856) - %2F %20 trick, invalid HOST header → [Win32/MacOSX only] Status bar link destination spoofing with invalid HOST header containing %2F (SA11856?)
Whiteboard: [sg:needinfo] → [sg:fix]
Depends on: 304904
Depends on: 304905
Split into two bugs:

bug 304904 - Firefox should refuse to look up invalid hostnames containing "%"
bug 304905 - UnEscapeURIForUI should leave %HH in hostname escaped

The combination of Firefox and Thunderbird will be secure against this type of
spoofing when at least one of those bugs is fixed.  Both should be fixed so that
Firefox can be secure with all forums/webmail/email clients, and Thunderbird can
be secure with all web browsers.
Flags: blocking1.8b4?
Whiteboard: [sg:fix] → [sg:fix] Split into bug 304904 and bug 304905
Whiteboard: [sg:fix] Split into bug 304904 and bug 304905 → [sg:spoof] Split into bug 304904 and bug 304905
It doesn't reproduce. 
The same error page as comment#1 is displayed. 

Mac OS X 10.3.9
Not use proxy.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20051222 Firefox/1.6a1
Camino trunk build  2005122123 (v1.0+)
Blocks: 325274
The essential bit, spoofing using %2f and other escapes in a host name has been fixed as bug 304904. Bug 304905 covers a "nice to have", showing the spoof in the status bar before the user clicks, but it's sufficient that the spoof won't load.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Flags: wanted1.8.0.x+
Keywords: fixed1.8
Whiteboard: [sg:spoof] Split into bug 304904 and bug 304905 → [sg:low spoof] Split into bug 304904 and bug 304905
You need to log in before you can comment on or make changes to this bug.