> 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
Received on Wed 14 Nov 2001 10:57:38 AM GMT
This archive was generated by hypermail 2.3.0 : Sat 13 Mar 2010 03:46:12 AM GMT GMT