From: Daniel Stenberg (Daniel.Stenberg@sth.frontec.se)
Date: Fri Jul 30 1999 - 07:05:22 CDT
On Fri, 2 Jul 1999, Paul Haldane wrote:
> Some sites (alright at least one site that I know well) are cautious
> about deploying the new version of hypermail with the ability to make
> ready decoded attachments available. Concerns relate to the possibility
> of a file infected with a macro virus being sent as an attachment and
> then 'run' directly from the web site.
This concern comes up every now and then. I don't understand the reason for
this worry. Could someone please share their wisdom and thell me a fully
possible way to attack a PROPERLY setup web server this way?
I am fully aware that we could mail an attachment with a .cgi attachment and
then the web server would run it if it had .cgi enabled for CGI scripts in
the directory it stores the attachments in. But why would the web server
allow ANY kind of CGI scripts in that directory?
If the server doesn't allow CGI scripts, how can the web server get affected?
The client on the other hand, will always be target to trojans and macro
viruses etc in the attachments that the happy user gladly will click on to
invoke in his local computer and network.
Anyway, with my suggestion below you can allow CGI scripts to be executed in
that directory AND the web server would still not be vulnerable to .cgi named
attachments.
> Now this is probably tackling the problem the wrong way round, but would
> it be possible/sensible to (optionally) have the link from the message to
> the attachment not going straight to the attachment but at some derived
> URL which forces the user browsing the archives through some sort of
> warning screen? (bit vague there - my feeling is that this is
> technically feasible - I'm not convinced it's a good idea).
I'm not against offering the ability to add such a wrapper script. It is a
very easy change, I suggest we make another %-replacement thing in hypermail
and allow the config file to specify something like:
attachment-link: %p
Where we can allow (just brainstorming freely atm):
%p for the full path to the attachment, as it is today
%f for the file name part only
%d for the directory name only
%n for the message number
%c for the content type string
So that if you'd want to make a warning screen for your silly users, you
could make it look similar to:
attachment-link: precaution.cgi?file=%f&number=%n&type=%c
This precaution.cgi script could do something like:
---- pseudo code start ----
$type = input type from command line
$file = input file name from command line
$number = input number from command line
print "Content-Type: $type\n\n";
printfile "$number/attachdir/$file";
---- end of pseudo code ---
This of course require that the script has other read-rights than the web
server and that the file is not readable by the web server. The attachments
must not be readable straight off the server by guessing the direct URL for
it.
(NOTE: I am here assuming that the attachments will be stored in its own
separate directory, as I believe we all want that and it makes a lot of
things easier both to the user(s) and to us authors.)
I'll happily receive any pointers to mistakes in my logic or thoughts. At
this moment I'm awaiting the latest flood of patches to get applied before I
take on any "major" bite of hypermail. I think one of the first things to do
is to make repeated invokes on hypermail on the same archive not keep
generating more and more attachments saved... ;-)
--
Daniel Stenberg - http://www.fts.frontec.se/~dast
ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol