RE: Secure popen

From: Glynn Clements (glynn.clementsat_private)
Date: Thu Jun 21 2001 - 22:12:41 PDT

  • Next message: Chris Ess: "Re: Secure popen"

    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