275417 - (sa13599) Download dialog source spoofing (Secunia Advisory SA13599 less critical)

Status: VERIFIED FIXED

(Toolkit :: Downloads API, defect)

Description

[Daniel Veditz [:dveditz]]

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]]

Attachment: spoof download source

Comment 2

[Daniel Veditz [:dveditz]]

[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:[e-mail]/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.

Comment 3

[Juha-Matti Laurio]

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/ ).

Comment 4

[Juha-Matti Laurio]

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.

Comment 5

[nrlz]

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]

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

Comment 7

[Ben Basson]

Attachment: Internet Explorer's Dialog

Screenshot of IE's dialog in this situation.

Comment 8

[Phil Ringnalda (:philor)]

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

Comment 9

[Juha-Matti Laurio]

(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]

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]]

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

Comment 12

[HJ]

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 ?

Comment 13

[Pritam Dutt Gautam]

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 [e-mail].
Generated Wed, 12 Jan 2005 09:49:47 GMT by redhat.codifyasia.local
(squid/2.5.STABLE5) 

Comment 14

[Mike Dallos]

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

Mike

Comment 15

[Juha-Matti Laurio]

> P.s. is this http://secunia.com/advisories/13599 ?

Yes, it is (mentioned in comment #3 and 'alias' field was updated).

Comment 16

[HJ]

(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.

Comment 17

[alex]

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

Comment 18

[chris hofmann]

lets try and get this for 1.0.1

ben, can we match IE' dialog?

Comment 19

[Greg]

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

Comment 20

[Asa Dotzler [:asa]]

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]]

Attachment: crop host on the left rather than right

Comment 22

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #21)
> crop host on the left rather than right

how about in the middle?

Comment 23

[George Deka]

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

Comment 24

[HJ]

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

Comment 25

[HJ]

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 ;)

Comment 26

[HJ]

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

Comment 27

[Ben Goodger (use ben at mozilla dot org for email)]

Comment on attachment 174296 [details] [diff] [review]
crop host on the left rather than right

r=[e-mail]

Comment 28

[Asaf Romano (gone)]

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).

Comment 29

[Daniel Veditz [:dveditz]]

Fixed on trunk

Comment 30

[Daniel Veditz [:dveditz]]

(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

[Asaf Romano (gone)]

> 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

[Asaf Romano (gone)]

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]]

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]]

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.

Comment 35

[Christopher Aillon (sabbatical, not receiving bugmail)]

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)]

Bug 285163 filed for seamonkey.