SBNelsonat_private wrote: > Please help me understand. What would be wrong with using popen(2) with > "/usr/lib/sendmail -oi -t" and passing the to/subject lines via input to > sendmail? The main issues are: 1. You are simply replacing the problem of a potentially malicious command-line argument with potentially malicious input on stdin. 2. You are losing the parameter boundary when you concatenate the user supplied data with the rest of the message headers. E.g. if the user can force a newline into the recipient address, they can insert arbitrary headers into the message. Whether or not this constitutes a genuine problem depends upon the specific details of the CGI program itself. > Is there something wrong with popen itself? The argument is fed through "/bin/sh -c"; if part of the argument is user supplied, the end result could be absolutely anything. E.g. snprintf(buff, sizeof(buff), "%s %s", cmd, arg); fp = popen(buff, "w"); This does /not/ invoke the command "cmd" with argument "arg". Or, rather, sometimes it does, sometimes it doesn't, depending upon exactly what "cmd" and "arg" are. "cmd" is presumably fixed by the program, but if "arg" is supplied by the user, it could contain spaces, semicolons, and anything else. E.g. cmd = "/usr/bin/foo" arg = "someargument ; rm -rf /" results in the shell being called to execute /usr/bin/foo someargument ; rm -rf / NB: this is exactly the same problem which makes system() insecure. It's better to do it manually with fork/exec (and maybe some other stuff between the two; you get the choice if you do it yourself). A "safe" popen() just needs pipe/dup2/fdopen thrown in on top of what's needed for a "safe" system(). Unfortunately libc doesn't include the obvious secure alternatives, and programmers often just take what's offered and overlook whether it's actually suitable. -- Glynn Clements <glynn.clementsat_private>
This archive was generated by hypermail 2b30 : Fri Jun 22 2001 - 10:31:00 PDT