Re: Saving attachments (was Re: MIME decoding patch)

On Fri, 30 Jul 1999, Daniel Stenberg wrote:

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

The concern here wasn't about the attachments crating a security problem for the server but rather by making it eay for someone browsing the generated web pages to run a possibly infected document.

Now my feeling is that the real solution is user education + sensible client configuration (up-to-date virus checks and using 'dumb' programs to open untrusted documents rather than macro enabled programs).

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

and the default would be something like

attachment-link: %p

which is effectively what we have now, yes?

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

That would be an enhancement and could be left as an exercise for the web administrator. I wouldn't worry too much about that - if the user is going to the trouble of guessing the url of the attachment and thus bypassing the warning, then that's their decision.

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

Agreed - though this isn't a problem with incremental updates and if you're rebuilding the whole thing then you could just empty the attachments directory before rebuilding.

Paul Received on Fri 30 Jul 1999 02:42:19 PM GMT