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)
Core
Security
Tracking
()
RESOLVED
FIXED
People
(Reporter: ostgote, Assigned: dveditz)
References
(Depends on 1 open bug, )
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.
Comment 1•20 years ago
|
||
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.
Comment 3•20 years ago
|
||
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.
Comment 4•20 years ago
|
||
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.
Comment 5•20 years ago
|
||
confirming Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040614 Firefox/0.9
Comment 6•20 years ago
|
||
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
Comment 7•20 years ago
|
||
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!
Assignee | ||
Comment 8•20 years ago
|
||
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
Comment 10•20 years ago
|
||
(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 ?
Assignee | ||
Updated•20 years ago
|
Whiteboard: [sg:needinfo]
Comment 11•20 years ago
|
||
Hmm.. I can also repro this on Windows but not Linux. Hmm.. that is very interesting. I tested Firefox 0.9 on Win2k.
Reporter | ||
Comment 12•20 years ago
|
||
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
Reporter | ||
Comment 13•20 years ago
|
||
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
Comment 14•20 years ago
|
||
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.
Comment 15•20 years ago
|
||
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?
Assignee | ||
Comment 16•20 years ago
|
||
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.
Comment 17•20 years ago
|
||
Yeah, UnescapeForUI is broken. We should never unescape %-escaped chars that appear in the hostname. Fixing that should help.
Comment 18•20 years ago
|
||
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?
Comment 19•20 years ago
|
||
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.
Reporter | ||
Comment 20•20 years ago
|
||
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.
Comment 21•20 years ago
|
||
Is www.heise.de x.e-gold.com a valid host name? (note that those are meant to be  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.
Comment 22•20 years ago
|
||
Or how about / (U+FF0F, hopefully)? Seems to be valid IDN here.
Comment 23•20 years ago
|
||
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.
Reporter | ||
Comment 24•20 years ago
|
||
(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.
Reporter | ||
Comment 25•19 years ago
|
||
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.
Updated•19 years ago
|
Flags: blocking1.8b4?
Comment 26•19 years ago
|
||
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?)
Updated•19 years ago
|
Whiteboard: [sg:needinfo] → [sg:fix]
Comment 27•19 years ago
|
||
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.
Updated•19 years ago
|
Flags: blocking1.8b4?
Whiteboard: [sg:fix] → [sg:fix] Split into bug 304904 and bug 304905
Assignee | ||
Updated•19 years ago
|
Whiteboard: [sg:fix] Split into bug 304904 and bug 304905 → [sg:spoof] Split into bug 304904 and bug 304905
Comment 28•19 years ago
|
||
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+)
Assignee | ||
Comment 29•17 years ago
|
||
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
Assignee | ||
Updated•17 years ago
|
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.
Description
•