considering the following lines
echo "test" | mail $USER -s "test"
mail will execute the command hidden in $USER.
when "mail" is replaced by "sendmail", no problem
that is a shell expansion problem, not a mail problem. the mailx
program has nothing to do with parameters shell expansion on its
Feedback from the user:
I doubt that , because the problem is _not_ triggered
when one uses
echo "test" | sendmail $USER
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
echo "test" | mail `/email@example.com -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
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 `/firstname.lastname@example.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.
------- 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 ?
This problem appears resolved.