From: Daniel Stenberg (daniel@haxx.se)
Date: Wed Nov 14 2001 - 02:51:21 CST
On Tue, 13 Nov 2001, Franklin DeMatto wrote:
> It seems like an attacker has full control over the filename, provided
> that he limits himself to those characters.
Yes, which I wouldn't call "full control". :-)
> Nothing is to stop an attacker from creating a .shtml attachment, and
> putting exec or include commands in it.
That is correct. But you can change how the links to the attachments are
created by editing the "attachmentlink" config file entry.
> This is a major insecurity, in my opinion.
I believe you're right.
> I would suggest that the "." character be removed from the list of
> acceptable characters, and possibly having hypermail append a standard
> extension. This would prevent an attacker from sending .shtml and the
> like, and would eliminate the possibility of a successful double dot
> exploit.
Well, as hypermail couldn't possibly know what extension the web server uses
for SSI pages, it would need to modify them all of course.
But, we've been there before. People want the attachments to use the same
extensions they have in the mails, as that'll make their clients better
equipped to fire up the correct local program to deal with them when the user
clicks on the links!
The "attachmentlink" config entry was added just for this reason, to give
admins the ability to make a "warning page" first that would warn users for
what might happen when he/she clicks on the link.
But, the SSI instructions would of course more likely cause harm in the
server end than in the client end, so a link to a warning page would be of no
use.
> As for the cross site scripting, I see no solution other then an option
> to disallow all attachments and MIME types other than text/plain. I did
> not see this option in the docs - I'll work on adding a patch. If
> someone could point out to me where the checks are made, it would save me
> some time :-).
I *think* you can do that with "ingore_types", as I believe that accepts
"wildcards"... So you can specify it to ignore all types. If that doesn't
work, that could be a spot to start patching at least.
> In terms of converting all < and > into < and >, could you point
> out where it is done? I would like to double check that no spots are
> missed - all parts of the message, including body, messageid, subject,
> etc. need to be checked.
The actual function that converts the letters is named 'convchars()' and is
found in the src/string.c source file.
There *could* be a spot somewhere where this isn't used, yes.
> > I believe that all files created by hypermail are chmod'ed to 0644 by
> >default. Altering this would require something like write access to ~/.hmrc.
> Can anyone else verify that there is no way to get hypermail to write
> files with a different mode?
I certainly won't *guarantee* it, but it looks like it is made pretty much
all over. The global variable 'set_filemode' is what keeps the 0644 number
that is possibly modified in the config file.
--
Daniel Stenberg - http://daniel.haxx.se - +46-705-44 31 77
ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol