considering the following lines export USER='`/sbin/reboot`@somewhere.org' echo "test" | mail $USER -s "test" mail will execute the command hidden in $USER. when "mail" is replaced by "sendmail", no problem arises.
that is a shell expansion problem, not a mail problem. the mailx program has nothing to do with parameters shell expansion on its command line.
Feedback from the user: I doubt that , because the problem is _not_ triggered when one uses echo "test" | sendmail $USER instead of echo "test" | mail $USER So it seems a shell expansion problem, but it is not triggered on the command line of "mail", but by "mail" itself, when it does it's own invoking of a shell. Sorry for wasting your time if i am still wrong.
Since you didn't understand the last explanation, I'll give it a try and see if I can explain more clearly and completely. The `...` sequence interpolates the output of the command ... into the command line. What you have posted is functionally equivalent to echo "test" | mail `/sbin/reboot`@somewhere.org -s "test" and, since the interpolation happens before any part of the line is executed, is functionally equivalent to /sbin/reboot. With $USER set the way you did, echo "test" | echo $USER > /dev/null will have the same effect. The mail and echo commands have absolutely nothing to do with this. Now you know one of many reasons why shell scripts are not used to write setuid programs... Calling this a bug is like complaining that a C program that calls system("/sbin/reboot"); shuts down the system when run as root. Yes, of course it shuts the system down; that's what you asked it to do. Hope that helps! You might consider getting a book such as O'Reilly's "Learning the bash Shell" that teaches shell syntax, if you are interested in delving further into the mysteries of shell programming. :-)
I feel we talk at cross-purposes. your echo-$USER-example won't execute the command. I typed it at the bash prompt. Instead it prints `/sbin/reboot`@somewhere.org' to the screen as I expected it to do. please review my report again.
I have been able to replicate this problem on a test machine in our lab. You have to be root for this to work. If you run this on the command line as a non-privileged user then it just says: reboot: must be superuser. It still boils down to be a bash issue and the way it interpolates.
sorry .. it's not a bash issue. if you strace /bin/mail you will see that "mail" starts a sub-shell calling /bin/echo and passing the dangerous parameter unquoted to /bin/echo at least you should put a note in the "mail"-man-page that it is not safe for root-scripting. :-) I know that because at our company we had a virus-scanner which replaced /usr/bin/procmail and was root-exploitable because it used /bin/mail at one place (for notification of the sender (sic) when a virus had been found in a mail attachment). We changed the virus scanner to use /usr/sbin/sendmail instead. cheers ------- Additional Comments From 10/18/99 19:28 ------- meanwhile I looked at the mailx source-code. It seems that "mail" invokes this "echo"-subshell with the explicit intention of evaluating shell meta characters. So in contrast to e.g. "procmail" it was never designed to handle its parameters in a secure way. However I cannot understand why mail does not rely on the script-writer to do any ``-substitutions himself ? it seems this expansion stuff inside of "mail" means that mail `echo root` mail "`echo root`" mail '`echo root`' have all the same effect (normally the last case would be different) - but why ? cheers
This problem appears resolved.