php.net |  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
Votes:1
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
 [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.

username=admin&password=password&LOGIN=+++Login+++

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 1.190.2.9.4.2
diff -u -u -r1.190.2.9.4.2 cgi_main.c
--- sapi/cgi/cgi_main.c 15 Feb 2003 22:56:04 -0000      1.190.2.9.4.2
+++ 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 */
        putenv(buf);
-       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...

Patches

Pull Requests

History

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 am3.baremetal.com 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: stripples.devel.redhat.com
Group       : System Environment/Libraries   Source RPM: glibc-2.2.4-31.src.rpm
Size        : 16370437                         License: LGPL
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
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";

  putenv(buf);
  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...

<?php 
  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   ">
</form>

the result is.

ENV[username] = admin&password=password&LOGIN=+++Login+++
POST[username] = admin
 [2003-02-21 03:14 UTC] sniper@php.net
Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

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 
php4-STABLE-200302210830
and that fix is a bit better, since it doesn't keep "delete requests" around.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Dec 26 23:01:28 2024 UTC