|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #22340 string to putenv() free()'d
Submitted: 2003-02-20 17:05 UTC Modified: 2003-02-21 03:26 UTC
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: tbrown at baremetal dot com Assigned:
Status: Closed Package: CGI/CLI related
PHP Version: 4.3.1 OS: linux
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Bug Type:
From: tbrown at baremetal dot com
New email:
PHP Version: OS:


 [2003-02-20 17:05 UTC] tbrown at baremetal dot com
the symptom is that with register_globals=on some variables are being incorrectly initialized.

This seems to be because the are being initialized from the environment instead from _POST

The environment is messed up, because the values passed to putenv() are being free'd an the memory is being recycled... it happens that the contents of the POST data are being copied into that location... e.g.


this shows up as an environment variable username, with the value admin&password=password&LOGIN=+++Login+++

which stomps on the POST value of "admin" ...

the fix seems to be

cvs diff -u sapi/cgi/cgi_main.c
Index: sapi/cgi/cgi_main.c
RCS file: /repository/php4/sapi/cgi/cgi_main.c,v
retrieving revision
diff -u -u -r1. cgi_main.c
--- sapi/cgi/cgi_main.c 15 Feb 2003 22:56:04 -0000
+++ sapi/cgi/cgi_main.c 20 Feb 2003 23:04:14 -0000
@@ -388,7 +388,7 @@
        /*  if cgi, or fastcgi and not found in fcgi env
                check the regular environment */
-       efree(buf);
+       /* Not safe! and in CGI, not a leak: efree(buf); */
        return 0;

although I don't know enough about fast-cgi to know if that is a memory leak or not...


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2003-02-20 17:09 UTC] tbrown at baremetal dot com
sorry, forgot a few details...

[tbrown@am3 /raid/home/tbrown/php4]$ uname -a
Linux 2.4.19 #1 SMP Fri Nov 1 20:43:44 PST 2002 i686 unknown
[tbrown@am3 /raid/home/tbrown/php4]$ rpm -qi glibc
Name        : glibc                        Relocations: (not relocateable)
Version     : 2.2.4                             Vendor: Red Hat, Inc.
Release     : 31                            Build Date: Thu 10 Oct 2002 10:09:11 AM PDT
Install date: Mon 18 Nov 2002 08:12:02 PM PST      Build Host:
Group       : System Environment/Libraries   Source RPM: glibc-2.2.4-31.src.rpm
Size        : 16370437                         License: LGPL
Packager    : Red Hat, Inc. <>
Summary     : The GNU libc libraries.
Description :

this C program demonstrates the problem...

[root@am3 ~]# more putenv.c 
#include <stdio.h>
#include <stdlib.h>

int main( int argc, char *argv[] ) {

  char buf[] = "TEST=initial value";

  printf("done store...\n");
  printf("getenv(TEST) returns: %s\n", getenv("TEST"));
  strcpy(buf,"TEST=new val");
  printf("done update...\n");
  printf("getenv(TEST) returns: %s\n", getenv("TEST"));

[root@am3 ~]# ./a.out 
done store...
getenv(TEST) returns: initial value
done update...
getenv(TEST) returns: new val
 [2003-02-20 17:21 UTC] tbrown at baremetal dot com
On the problem machine, this is enough to reproduce the problem... it is fairly finicky though, as to be expected for a memory layout issue... the spaces in the submit button value are significant...

  if ($username) {
    // system("/var/www/cgi-bin/printenv");
    print "ENV[username] = $_ENV[username] <br>\n";
    print "POST[username] = $_POST[username] <br>\n";

<form method=post>
   <input name=username value=admin8020>
   <input name=password value=password>
   <input type="submit" name="LOGIN" value="   Login   ">

the result is.

ENV[username] = admin&password=password&LOGIN=+++Login+++
POST[username] = admin
 [2003-02-21 03:14 UTC]
Please try using this CVS snapshot:
For Windows:

This should be fixed already..

 [2003-02-21 03:25 UTC] tbrown at baremetal dot com
yes, it does look like it is fixed in 
and that fix is a bit better, since it doesn't keep "delete requests" around.
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Fri Sep 24 18:03:38 2021 UTC