To go along with the download box spoof reported in bug SA12712 Jakob Balle submits a demonstration to make the download dialog more convincing by obscuring the software source. The demo takes advantage of the default length truncation (similar to truncation of the filename in bug 258601). While the dialog /can/ be resized to see the whole url, most people won't think to do that or even know it's possible.

[SA12712 mentioned above is bug 262887] The download request dialog is implemented differently in Mozilla: in the suite middle of the URL is elided. A different form of spoofing URL might be pretty convincing there. Thunderbird is possibly vulnerable. In most places link clicking takes you to the external browser and javascript is disabled, but I believe JS is enabled for RSS feed pages. Replacing the top location might be disabled (I hope so), but you could have such a url in an iframe. Probably harder to construct a believable spoof from an RSS feed--as opposed to mail supposedly from your bank--though it's remotely possible: a professional, multi-media related site with improperly sanitized comments might allow for a bogus "upgrade your media player" spoof. Seems remote, and fixing the toolkit for Firefox will fix tbird. Both Firefox and the Suite display user:pass in the URLs. These should be stripped as they are from the location bar, otherwise this spoof is even easier with "http://www.citibank.com:user_security_upgradeblahblah@evil.com/etc". The spoof is marred by the spoofed auth prompt, but if evil.com actually asks for authentication it could possibly be socially engineered as believable for any target site that requires a login of some sort (e.g. a bank). Note: phishing shows that even if this bug is fixed, people will still fall for URLs like www.citibank-support.com or similar variations.

Secunia has released their research as an advisory http://secunia.com/advisories/13599/ today, affecting both to Firefox and Suite, newest version. Their severity is 'Less critical'. (There is their own advisory too; http://secunia.com/secunia_research/2004-15/advisory/ ).

Some experiences: Secunia's solution is to avoid downloading from untrusted sources (so download links opened by JS, 'javascript:launchDLWindows();' in this attachment (com#1). Observing of the Status Bar is important, again. In FF it is possible to select text at From: row by mouse in Opening filename.ext window. It discloses an invisible part of the path text, the part just after the text '.com' and several spaces in this issue. 3rd way is to check the source path in Downloads window with right mouse-button's Properties, row 'From:', when download is finished. An _experienced_ user can examine path containig possible several spaces or suspicious names like citibank-software-server.new-netbank.citibank.com If user is not 100% sure of source, he/she can 'Remove' it yet.

Do we have to display the entire path of the file? When we are forming trust, we only rely on the domain, right? If we only show the domain, we can right align the text which will ensure that the most significant part is visible. We can then show the URL path in a tooltip or something.

Internet Explorer doesn't show the directory tree after the domain and truncates the subdomain string if necessary.

Screenshot of IE's dialog in this situation.

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

(In reply to comment #7) > Internet Explorer's Dialog > > Screenshot of IE's dialog in this situation. Behaviour is similar in XP and SP2 too (no possibility to make an attachment just now, W2K used in com#7's screenshot?), but I think we should favour this principle in cutting the subdomain string. By the way, Netscape 7.2 is not affected, its dialog box shows extra spaces in test case (comment#1), and several dots after the word new-netbank, actually just after letters new-ne.

What about severity now, it's 'critical' in duplicate; #277184. Secunia ranked this as 'Less critical' 2/5, ISS X-Force Database as 'Medium Risk' 2/3. Both advisories contain Mozilla and FF as affected. There is no ranking system available in every security companies.

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

What about having two fields/lines? The first with the host/domain name and the second one with the URL, if possible, or the last part only, when the URL can't be displayed on total. P.s. is this http://secunia.com/advisories/13599 ?

When used behind SQUID user can't reach the specified URL .. the message such shown is ERROR The requested URL could not be retrieved While trying to retrieve the URL: http://citibank-software-server.new-netbank.citibank.citibank-software-server.new-netbank.citibank.com%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0.secunia.com/temp/test.php The following error was encountered: * Invalid URL Some aspect of the requested URL is incorrect. Possible problems: * Missing or incorrect access protocol (should be `http://'' or similar) * Missing hostname * Illegal double-escape in the URL-Path * Illegal character in hostname; underscores are not allowed Your cache administrator is pd@codifyasia.local. Generated Wed, 12 Jan 2005 09:49:47 GMT by redhat.codifyasia.local (squid/2.5.STABLE5)

Thanks all.........be well....... Mike

> P.s. is this http://secunia.com/advisories/13599 ? Yes, it is (mentioned in comment #3 and 'alias' field was updated).

(In reply to comment #15) > > P.s. is this http://secunia.com/advisories/13599 ? > > Yes, it is (mentioned in comment #3 and 'alias' field was updated). Hey, I was fully aware of it, but I tried to trigger attention because A) there was no URL to this Secunia Advisory and B) no confirmation of this bug being the same thing and C) expected someone to update the summary too, however, as of today, that's still not the case, so lets make it easier for people to locate this bug report.

What about wrapping the download path in the horrid <marquee>'s if too long or wrapping over multiple lines?

lets try and get this for 1.0.1 ben, can we match IE' dialog?

Would there be any value in providing an API for a Baysean Analylser to hook to (like the one for spam disposal - Bogofilter)? It would analyse URLs so that a phishing probability could be flagged to the unwary surfer. Eg a little icon, next to the address bar (skull & crossbones :o) ). It could come with a hardwired link to a trusted site containing a constantly updated whitelist for download occasionally. I guess performance might be an issue - just a thought tho' cheers, Greg

Ben, Dan, are either of you able to look at this? Time is short for 1.0.1 and this needs to be fixed there.

(In reply to comment #21) > crop host on the left rather than right how about in the middle?

What if we wrapped the address over a few lines, that way the whole thing would show. and be better than IE

What about using something like this: http://multizilla.mozdev.org/screenshots/features/xpinstall/xpinstall-confirm-v3-items.jpg

Oh, before I forget, I also have something like this: http://multizilla.mozdev.org/screenshots/features/xpinstall/xpinstall-confirm-v3-contextmenu.jpg I'm sure you don't want/need all of it, but most people seem to like it ;)

Yikes, wrong bug report, sorry for the spam :-(

Comment on attachment 174296 [details] [diff] [review] crop host on the left rather than right r=ben@mozilla.org

Comment on attachment 174296 [details] [diff] [review] crop host on the left rather than right Daneil, in order to make this work in a rtl gui, please change the following: >+ <description id="location" class="plain" crop="start" flex="1"/> to: >+ <description id="location" class="plain uri-element" crop="start" flex="1"/> (That's becuase "start" means "right" when the element direction is rtl... and URIs should always be ltred anyway) For reference, here is the .uri-element definition: 51 textbox.uri-element, 52 menulist.uri-element 53 { 54 direction: ltr !important; 55 } you'll need to add "description"... or use "dir="ltr" rather than using the uri-element class).

Fixed on trunk

(In reply to comment #28) > (That's becuase "start" means "right" when the element direction is rtl... and > URIs should always be ltred anyway) That sounds like a separate bug, I didn't change the text direction of anything here so presumably this text has been OK being rtl until now. "location" is poorly named, that's the filename. "source" is the more uri-like, though this patch shortens it from host+path to simply host.

> crop host on the left rather than right Daniel, if it was cropped by crop="end" (i.e. the bug wasn't exist in a rtl gui). (and now it isn't).

ooops, writing agin: > crop host on the left rather than right Daniel, if it was cropped by crop="end", then it was OK for rtl (i.e. the bug wasn't exist in a rtl gui, and now it is). adding dir="ltr" seems to be the way to go. we already apply it to many elements in seamonkey and thunderbird (using the urielement class).

I'm not getting it, please post a screenshot of what the spoofed dialog looked like in a RTL locale prior to my fix (click a link in attachment 169226 [details]). Do the text blocks not get reversed, only the text within each block? I think it would be clearer and far less confusing to simply file whatever RTL problems you see with this dialog as a separate bug. Assign it to me or cc me so I see it.

Verified Fixed with 2/21 Aviary and Trunk builds. Host is cropped on the left, correctly displaying "secunia.com" on the right with the attached testcase.

Wait. The secunia advisory notes that this affects 1.7.x as well. Don't we need a fix for xpfe, and an appropriate checkin to 1.7? If it already has happened, then please mark fixed1.7.6 but I assume the patch is slightly different here...

Bug 285163 filed for seamonkey.