Last Comment Bug 275417 - (sa13599) Download dialog source spoofing (Secunia Advisory SA13599 less critical)
: Download dialog source spoofing (Secunia Advisory SA13599 less critical)
: fixed-aviary1.0.1
Product: Toolkit
Classification: Components
Component: Downloads API (show other bugs)
: unspecified
: All All
: -- normal with 7 votes (vote)
: ---
Assigned To: Daniel Veditz [:dveditz]
: Ali Ebrahim
: :Paolo Amadini
: 277184 277503 (view as bug list)
Depends on: SA12712
Blocks: sg-ff101 sg-moz176
  Show dependency treegraph
Reported: 2004-12-20 12:02 PST by Daniel Veditz [:dveditz]
Modified: 2014-04-26 03:32 PDT (History)
32 users (show)
chofmann: blocking‑aviary1.0.1+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

spoof download source (595 bytes, text/html)
2004-12-20 12:04 PST, Daniel Veditz [:dveditz]
no flags Details
Internet Explorer's Dialog (5.61 KB, image/png)
2005-01-05 13:01 PST, Ben Basson
no flags Details
crop host on the left rather than right (3.32 KB, patch)
2005-02-14 08:51 PST, Daniel Veditz [:dveditz]
bugs: review+
dbaron: approval‑aviary1.0.1+
Details | Diff | Splinter Review

Description Daniel Veditz [:dveditz] 2004-12-20 12:02:32 PST
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.
Comment 1 Daniel Veditz [:dveditz] 2004-12-20 12:04:04 PST
Created attachment 169226 [details]
spoof download source
Comment 2 Daniel Veditz [:dveditz] 2004-12-20 12:46:41 PST
[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 "". The
spoof is marred by the spoofed auth prompt, but if 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 or similar variations.
Comment 3 Juha-Matti Laurio 2005-01-04 04:16:15 PST
Secunia has released their research as an advisory today, affecting both to Firefox and Suite,
newest version. Their severity is 'Less critical'. (There is their own advisory too; ).
Comment 4 Juha-Matti Laurio 2005-01-04 12:56:39 PST
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

If user is not 100% sure of source, he/she can 'Remove' it yet.
Comment 5 nrlz 2005-01-04 22:35:43 PST
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.
Comment 6 Ben Basson 2005-01-05 12:38:56 PST
Internet Explorer doesn't show the directory tree after the domain and truncates
the subdomain string if necessary.
Comment 7 Ben Basson 2005-01-05 13:01:09 PST
Created attachment 170382 [details]
Internet Explorer's Dialog

Screenshot of IE's dialog in this situation.
Comment 8 Phil Ringnalda (:philor) 2005-01-05 13:36:06 PST
*** Bug 277184 has been marked as a duplicate of this bug. ***
Comment 9 Juha-Matti Laurio 2005-01-05 13:48:07 PST
(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.
Comment 10 Juha-Matti Laurio 2005-01-05 14:12:50 PST
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.
Comment 11 Daniel Veditz [:dveditz] 2005-01-08 01:34:34 PST
*** Bug 277503 has been marked as a duplicate of this bug. ***
Comment 12 HJ 2005-01-11 17:36:14 PST
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 ?
Comment 13 Pritam Dutt Gautam 2005-01-12 02:08:36 PST
When used behind SQUID user can't reach the specified URL .. the message such
shown is 

The requested URL could not be retrieved

While trying to retrieve the URL:

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
Comment 14 Mike Dallos 2005-01-12 04:26:26 PST
Thanks well.......

Comment 15 Juha-Matti Laurio 2005-01-17 12:44:16 PST
> P.s. is this ?

Yes, it is (mentioned in comment #3 and 'alias' field was updated).
Comment 16 HJ 2005-01-17 14:07:46 PST
(In reply to comment #15)
> > P.s. is this ?
> 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.
Comment 17 alex 2005-01-27 10:57:58 PST
What about wrapping the download path in the horrid <marquee>'s if too long or
wrapping over multiple lines?
Comment 18 chris hofmann 2005-02-02 12:51:06 PST
lets try and get this for 1.0.1

ben, can we match IE' dialog?
Comment 19 Greg 2005-02-10 00:43:33 PST
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'


Comment 20 Asa Dotzler [:asa] 2005-02-10 13:08:03 PST
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.
Comment 21 Daniel Veditz [:dveditz] 2005-02-14 08:51:07 PST
Created attachment 174296 [details] [diff] [review]
crop host on the left rather than right
Comment 22 Christian :Biesinger (don't email me, ping me on IRC) 2005-02-14 13:15:41 PST
(In reply to comment #21)
> crop host on the left rather than right

how about in the middle?
Comment 23 George Deka 2005-02-14 21:58:03 PST
What if we wrapped the address over a few lines, that way the whole thing would
show. and be better than IE
Comment 25 HJ 2005-02-15 03:23:00 PST
Oh, before I forget, I also have something like this:
I'm sure you don't want/need all of it, but most people seem to like it ;)
Comment 26 HJ 2005-02-15 03:25:31 PST
Yikes, wrong bug report, sorry for the spam :-(
Comment 27 Ben Goodger (use ben at mozilla dot org for email) 2005-02-17 14:29:46 PST
Comment on attachment 174296 [details] [diff] [review]
crop host on the left rather than right
Comment 28 Mano (::mano, needinfo? for any questions; not reading general bugmail) 2005-02-17 14:45:18 PST
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"/>


>+      <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).
Comment 29 Daniel Veditz [:dveditz] 2005-02-18 04:15:38 PST
Fixed on trunk
Comment 30 Daniel Veditz [:dveditz] 2005-02-18 04:34:34 PST
(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.
Comment 31 Mano (::mano, needinfo? for any questions; not reading general bugmail) 2005-02-18 07:03:17 PST
> 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).
Comment 32 Mano (::mano, needinfo? for any questions; not reading general bugmail) 2005-02-18 07:06:49 PST
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).
Comment 33 Daniel Veditz [:dveditz] 2005-02-18 11:56:12 PST
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.
Comment 34 Jay Patel [:jay] 2005-02-23 15:23:18 PST
Verified Fixed with 2/21 Aviary and Trunk builds.  Host is cropped on the left,
correctly displaying "" on the right with the attached testcase.
Comment 35 Christopher Aillon (sabbatical, not receiving bugmail) 2005-03-07 08:06:42 PST
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...
Comment 36 Christopher Aillon (sabbatical, not receiving bugmail) 2005-03-07 12:10:24 PST
Bug 285163 filed for seamonkey.

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