5

I have a bash script which I'm kicking off via procmail. Procmail passes in the subject and from field from an email as arguments to the bash script. Since these values are unsanitized in any way, I'm trying to figure out if there are any injection vulnerabilities in bash that someone could take advantage of and if so what I can do to protect against these. Here is some sample code to illustrate what's going on :

#!/bin/bash
/usr/sbin/sendmail -t <<EOF
From: "myhost Administrator" <admin@myhost.example.com>
To: john_doe@gmail.com
Subject: An email subject

You've received a new email.
It has a subject of "$2"
It was sent from "$1".
EOF

This bash script would be called by procmail with a .procmailrc script like this :

:0
* ^From:\s*\/.*
{
 FROM = "$MATCH"
}

:0
* ^Subject:\s*\/.*
{
 SUBJECT = "$MATCH"
}

:0 c:
* ^To:.*@example.com
| /home/john_doe/examplescript.bash "$FROM" "$SUBJECT"

The two areas that I'm wondering about injection vulnerabilities for are in the instantiation of the script :

/home/john_doe/examplescript.bash "$FROM" "$SUBJECT"

and the usage of the variables in the script.

/usr/sbin/sendmail -t <<EOF
From: "myhost Administrator" <admin@myhost.example.com>
To: john_doe@gmail.com
Subject: An email subject

You've received a new email.
It has a subject of "$2"
It was sent from "$1".
EOF

If your curious, here is the actual use case that brought this question to my mind

gene_wood
  • 1,960
  • 4
  • 26
  • 39

3 Answers3

1

To avoid the problems of injection, you could also just pipe all messages to the address you care about through a script which reads the message off of stdin and natively parses out the headers that interest you.

You could then use libraries available in the scripting language you chose to speak SMTP to your locally running mail server.

This way, there's no command execution, and theres no need to worry about unsanitized input being used as arguments to a program.

mkomitee
  • 760
  • 6
  • 10
  • This sounds like a good holistic solution which will address all possible vulnerabilities. It's more work but I think you're right that it will avoid injection problems. Thanks! – gene_wood Jan 04 '11 at 23:35
0

I'm not a security expert, but injection vulnerabilities exist in any non-sanitized user input -- especially if you're sending that raw input to system commands that may have privileged access. Always verify your input before doing that.

Check $1 and $2 to make sure they contain only printable characters and are a reasonable length, like under 1000 characters, before sending them off to your mail system.

That's not too difficult to do, and it prevents you from getting hit from some unknown exploit.

One of the things I like about Perl is the taint mode that prevents you from doing things like this unless you've cleaned up the data first.

David W.
  • 105,218
  • 39
  • 216
  • 337
  • Good ideas, stripping the strings to printable characters and setting a max length. I can enforce that within the script, but at the execution of the script I'm not sure I'd be able to sanitize the strings within procmail. I'll look into that. – gene_wood Jan 03 '11 at 21:09
  • @gene_wood you can both limit the variables and strip them of non-printables natively via Parameter Expansion. For example: `${1::10}` will limit the first input parameter to a length of 10 chars. To remove all non-printables you would do `${1//[^[:print:]]/}`. So to put it all together: `oneLen=${1::10};oneClean=${oneLen//[^[:print:]]/}`. Man `tr` if you want a complete list of character classes you can use such as `[:alnum:]` or `[:digit:]` etc. – SiegeX Jan 04 '11 at 07:40
0

The shell script in itself is pretty safe. The most vulnerable part of a mail is the header, and you don't allow the mail sender to change anything in it.

The only way I see in the script is that someone could pass a dot on a single line, which would end the mail prematurely. And there may be the case of embedding attachments using uuencode like this:

Subject: subject
From: sender@example.com
To: receiver@example.com

text line 1
text line 2

begin 644 file-containing-abc
$86)C"G]_
`
end

I'm worried about the line in the .procmailrc, since I don't know the quoting rules. This might be a point where an attacker could inject code, so you need to look up the rules in the manual and test them to be sure. Some characters you should test are $, ", \, newlines.

Roland Illig
  • 40,703
  • 10
  • 88
  • 121
  • Roland, good ideas. I'll do some testing against common characters that might bypass quoting and comment back here with what I find. – gene_wood Jan 03 '11 at 22:46