securing a remailer

[geektron]

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?

[marto]

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

[neosamuri]

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.

[schweini]

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?

[geektron]

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.

[sgifford]

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.