Saving attachments (was Re: MIME decoding patch)

From: Daniel Stenberg <Daniel.Stenberg_at_sth.frontec.se_at_hypermail-project.org>
Date: Fri, 30 Jul 1999 14:05:22 +0200 (MET DST)
Message-ID: <Pine.GSO.4.10.9907301332090.6930-100000_at_metal.sth.frontec.se>

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

Received on Fri 30 Jul 1999 02:04:50 PM GMT