From nobody@hyperreal.com Tue Feb 18 14:44:38 1997 Received: by taz.hyperreal.com (8.8.4/V2.0) id OAA00289; Tue, 18 Feb 1997 14:44:38 -0800 (PST) Message-Id: <199702182244.OAA00289@taz.hyperreal.com> Date: Tue, 18 Feb 1997 14:44:38 -0800 (PST) From: Enrik Berkhan Reply-To: enrik@inka.de To: apbugs@hyperreal.com Subject: suEXEC wrapper allocates PATH on the stack X-Send-Pr-Version: 3.2 >Number: 179 >Category: mod_cgi >Synopsis: suEXEC wrapper allocates PATH on the stack >Confidential: no >Severity: non-critical >Priority: medium >Responsible: apache >State: closed >Class: sw-bug >Submitter-Id: apache >Arrival-Date: Tue Feb 18 14:50:00 1997 >Last-Modified: Fri Feb 21 11:22:02 PST 1997 >Originator: enrik@inka.de >Organization: >Release: 1.2b6 >Environment: Debian/GNU Linux 1.2 Linux quechua 2.0.27 #4 Thu Dec 5 22:57:45 MET 1996 i586 gcc version 2.7.2.1 libc.so.5.4.13 >Description: Within the clean_env function, the buffer for the newly set PATH environment variable is allocated on the stack. If the buffer would be used up to its end, even the subsequent call to exec could overwrite parts of the buffer before the exec can copy the environment. The situation gets even worse if somebody decides to extend suexec.c and to call other functions between clean_env() and execv(). >How-To-Repeat: try a (pathologic ;-) SAFE_PATH in suexec.h of nearly 512 characters >Fix: change the variable to stati >Audit-Trail: State-Changed-From-To: open-analyzed State-Changed-By: marc State-Changed-When: Wed Feb 19 15:39:22 PST 1997 State-Changed-Why: Problem verified. Thanks for the report. What we will probably do is just do a strdup() on it... State-Changed-From-To: analyzed-closed State-Changed-By: marc State-Changed-When: Fri Feb 21 11:22:02 PST 1997 State-Changed-Why: Fixed in revision 1.18 of suexec.c which will be available in the next beta. Thanks. >Unformatted: