From: Craig A Summerhill (craig@cni.org)
Date: Tue Apr 20 1999 - 05:10:26 CDT
On Sun, 18 Apr 1999, Daniel Stenberg <dast@sth.frontec.se> wrote:
>
> On Fri, 16 Apr 1999, Ron Brogden <rb@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@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@cni.org AT&Tnet (202) 296-5098