I was about to say there is no problem at all because of the way
Tcl quotes arguments to exec. However, there is good and bad news.
The good news is that you cannot hide a pipe symbol in the email
address in order to run an arbitrary program. The bad news is that
you can put redirection symbols like < and > in there to cause some trouble.
My "argecho" script is a csh script that echos its arguments:
% exec /home/welch/bin/argecho foo bar
arg-0 foo
arg-1 bar
% set pipe "|nasty"
|nasty
% exec /home/welch/bin/argecho foo $pipe
arg-0 foo
arg-1 |nasty
So, you see that the literal string "|nasty" was passed into the
program as an argument - exec did not parse it out.
However,
set redir ">steal"
exec /home/welch/bin/argecho x $pipe $redir
(no output to the screen)
cat steal
arg-0 x
arg-1 |
arg-2 cat
Also, with both < and << specified, << wins, so you cannot try
setting the email to "</etc/passwd" to yourself:
% set email "welch </etc/passwd"
welch </etc/passwd
% exec /usr/lib/sendmail $email << $msg
welch </etc/passwd... Unbalanced '<'
welch </etc/passwd... Cannot mail directly to files
/home/welch/dead.letter... Saved message in /home/welch/dead.letter
child process exited abnormally
The worst attack seems to be a file overwrite:
% set email ">steal"
>steal
% exec /usr/lib/sendmail $email << $msg
% cat steal
welch... Recipient names must be specified
(msg contains "To: welch)
>>>Kristoffer Lawson said:
>
> I noticed that in mail.tcl you directly pass the given email address
> to sendmail in exec. The command is as follows:
>
> exec $Mail(program) $sendto << $message
>
> I believe there might be a possibility for a security issue here if the
> user is able to set the email address to something containing those
> magic characters used by exec (like >). I have not yet studied thoroughly
> if this is actually possible in any circumstances and it would be nice to
> be assured that this is secure.
>
> I stumbled across this while building my own software using sendmail in a
> similar fashion. Apparently there is no easy way of dealing with this, as
> there are no (documented) escape characters to exec. The clean solution to
> this would be to provide a secure exec where the input/output options have
> to be given as actual options as in:
>
> newExec -outputToFile /dev/null ls /
>
> (one might argue that this is cleaner than using the special characters)
>
> Alternatively the command could be given as one string:
>
> anotherExec "ls /" > /dev/null
>
> - ---------- = = ---------//--+
> | / Kristoffer Lawson | www.fishpool.fi|.com
> +-> | [EMAIL PROTECTED] | - - --+------
> |-- Fishpool Creations Ltd - / |
> +-------- = - - - = --------- /~setok/
>
-- Brent Welch <[EMAIL PROTECTED]>
http://www.ajubasolutions.com
Scriptics changes to Ajuba Solutions
scriptics.com => ajubasolutions.com
