Re: MIME disable option? (hopefully not FAQ)

From: Craig A Summerhill <craig_at_cni.org_at_hypermail-project.org>
Date: Tue, 20 Apr 1999 06:10:26 -0400 (EDT)
Message-Id: <9904201010.AA03714_at_a.cni.org>

On Sun, 18 Apr 1999, Daniel Stenberg <dast_at_sth.frontec.se> wrote:
>
> On Fri, 16 Apr 1999, Ron Brogden <rb_at_islandnet.com> wrote:
> >
> > People should not be sending them to a list in the first place and I want
> > to avoid any potential security issues this might lead to.
>
> I am aware that the current way of storing attachments using the supplied
> name may offer ways to screw up the web server, such as your .htaccess
> example. However, instead of disabling the feature I would rather like to
> hear suggestions on how to avoid the risks.

Daniel,

When Kent initially raised the possibility of a version 2.x of hypermail, I proposed that attachements be stored in some type of sub-directory structure. Part of my proposal was due to security concerns.

I still think some substructure is a GOOD THING (emphasis deliberate), especially if you could add an element of randomness to the creation of that substructure -- which could be used to deter would be crackers. However, as Tom von Alten <Tom_vonAlten_at_boi.hp.com> noted, while a substructure might protect your master directory, it doesn't necessarily protect the substructure itself... and that could endanger your entire server...

I think Tom's second solution is ultimately, the one that is most likely to be fruitful (e.g. a list of forbidden or restricted filenames). In addition to the obvious '.htaccess' file, I would also propose the following be added to a "default" omit list. And the list should be locally extensible:

   robots.txt
   index.html

Finally, I would propose a fourth (4) option for an approach to handling MIME attachments:

   o have hypermail write the MIME attachment out to a file (either

      in the master directory or in a sub-directory structure).

   o set the permissions on the file to 000.

   o have hypermail send an e-mail note to the web administrator

      (or otherwise defined administrator) telling them to review 
      the file and change the permissions to 644 on the file in 
      order to make it accessible.  Thus, the markup of the base 
      archives is automatic, but the MIME attachments require 
      review.

   o  of course, this feature needs to be something which can be 
      switched on/off.  On the lists I use hypermail for, this would 
      be manageable because I discourage MIME and we moderate the 
      postings to the lists.  There are very few messages (I'll 
      guess 1 in 10,000) that really needs to store a MIME attachment.
      But I can imagine venues where moderation of attachments is 
      unmanageable.

This approach wouldn't require much additional work to add in to the existing code. All you need to do is some printf statements to format a message and identify a person to send it to (in the global settings of local .hmrc file).

Just my $.02

I just thought of a fifth (5) possible approach... maybe.

You might be able to use some kind of global hypermail cgi script (presumably installed in the master /cgi-bin directory as defined by cgidir in the top level Makefile) to mask the path name of the MIME attachments which are being called/written. I have seen some servers do something like this with CGI or JavaScript. If you examine the HTML of the files, there is no indications of the real path to the file. But clicking on an icon or hyperlink causes a server-side handler to serve the file up. Presumably, it could be as easy as a Perl script which does

sub ServeItUp {

  print <<EOF;

Content-type: $mime-type

stream the file

}

I'll try to think this out some more, but I think you could securely make the attachments available to clients and effecitvely prevent crackers from getting into the server. Even if they write some kind of 'bad' file to the server, they probably can't do much with it unless they know the path...

-- 

   Craig A. Summerhill, Systems Coordinator and Program Officer
   Coalition for Networked Information
   21 Dupont Circle, N.W., Washington, D.C.   20036
   Internet: craig_at_cni.org   AT&Tnet (202) 296-5098

Received on Tue 20 Apr 1999 12:11:10 PM GMT