What, if any, injection vulnerabilities are there in bash and how can I protect against them?
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
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.
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.
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.
精彩评论