On Wed, 20 Jun 2001, Antonomasia wrote: > popen() with "/usr/lib/sendmail -oi -t" would be fine in this particular > case (provided the environment was reset - CGI usage being discussed > and I don't know exactly what environment you can pass that way) > where the command line can be chosen as a fixed value. More generally > where some user input makes it into the command line exec*() is preferable > as it avoid shells and all their interpretation. Yes. The real question is "what and how is affected by the (untrusted) user input...and untrusted environment, and how is the result interpreted?" As long as no single bit of untrusted data can affect the argument of popen(), the environment variables, nor the interpretation of given commands (like $PATH==.:/bin:/usr/bin and $PWD==/tmp on a multiuser machine), popen() is as good as anything else (and ironically, it can be even better because you have an obvious reason to be careful). <rant> If only people knew more about the theoretical background of information security--about information flows, noninterference and such things... </rant> An interesting point is that you might need to check your input even when it does not affect anything but the contents of a message being sent. For instance, if some of the untrusted input is included into its headers, you certainly do not want to put a text like ``blah blah\nMIME-Version: 1.0\n Content-Type=multipart/mixed; boundary="xyz"\n\n--xyz\nContent-Type: text/plain\n\nGotcha!\n--xyz--\n\n'' (replace \n's with \r\n if the text is submitted via SMTP) there. --Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ] "Resistance is futile. Open your source code and prepare for assimilation."
This archive was generated by hypermail 2b30 : Sun Jun 24 2001 - 10:47:57 PDT