securing a remailer

geektron has asked for the wisdom of the Perl Monks concerning the following question:

One of our ancient remailer scripts has finally been compromised. Someone discovered that it uses an ancient method to pass infomation to sendmail: a pipe directly to sendmail - the worst way to send email from a script.

I'm rewriting the thing with an extra eye for security and configurability (so that I can reuse it across our sites, if/when needed), and I want to make sure I've covered all the bases since the PHB keeps throwing "what if ...." scenarios at me.

I've already come up with the following to secure this thing:

using the -T switch (which isn't in the original)
using MIME::Lite to create the message rather than just printing to sendmail
using Mail::Address or something similar to validate the "To:" field in the messages. i'll probably also make sure that only *one* value is in the "To:" field
(not security related) using Config::General to allow for config file creation with an eye for deploying the remailer across sites.

I know that checking for $ENV{HTTP_REFERER} isn't a great option, because that can be spoofed. (the person(s) exploiting this hole in the existing remailer have already spoofed IPs to allow for more hits to the script.

Does adding some form of key/ session_id buy any security? I think not, because it would be just another thing that needs to be passed in the form, and enough brute-force attacks would crack that too ...

Any other suggestions for making this thing as locked down as possible?

Comment on securing a remailer Select or Download Code

Replies are listed 'Best First'.
Re: securing a remailer by marto (Cardinal) on Oct 11, 2005 at 21:38 UTC
Hi, You may want to have a look at NMS Formmail. If you really wanted to roll your own you may get some ideas from it. If its features and config match your requirements you may just want to use it. I have used it in a previous job at an ISP when the existing mail gateway sciprt given to users was found to have a rather serious flaw in it. This topic has been touched on before, you may want to do a Super Search. Hope this helps. Martin	[reply]
Re: securing a remailer by neosamuri (Friar) on Oct 11, 2005 at 21:40 UTC
Does adding some form of key/ session_id buy any security? I think not, because it would be just another thing that needs to be passed in the form, and enough brute-force attacks would crack that too ... I don't know much about security programing, but I remeber hearing somewhere For every door there is a key, which means that no matter what you do someone given enough knowledge, skill and motivation can still get in. So adding the key/ session_id would make it better in the sense that, it would require more motivation for someone to get through it.	[reply]
Re: securing a remailer by schweini (Friar) on Oct 12, 2005 at 03:25 UTC
an ancient method to pass infomation to sendmail: a pipe directly to sendmail - the worst way to send email from a script. just wondering why this is that bad? i still use that for quick-n-dirty plain-text mailers, and wasn't aware of any security/abuse problems with this?	[reply]
Re^2: securing a remailer by geektron (Curate) on Oct 12, 2005 at 03:54 UTC
if user input isn't validated/untainted, newlines can be passed into the input, allowing someone to hijack the script and use it as a spam-remailer. sure, if you're not accepting user input you could get away with it, but i don't recommend it.	[reply]
Re^3: securing a remailer by sgifford (Prior) on Oct 12, 2005 at 15:41 UTC
So the solution is to validate user input. No need to throw the baby out with the bathwater. You'd have similar problems with using unvalidated input with SMTP or any other mechanism for sending mail. Still, if the OP finds they can replace a significant chunk of their code with a well-maintained Perl module, that seems like a pretty clear good idea.	[reply]