Home page logo
/

fulldisclosure logo Full Disclosure mailing list archives

Re: PHP import_request_variables() arbitrary variable overwrite
From: Stefano Di Paola <stefano.dipaola () wisec it>
Date: Sat, 10 Mar 2007 17:06:06 +0100

Hi Stefan,

first of all let me say i come in peace :)

Il giorno sab, 10/03/2007 alle 15.17 +0100, Stefan Esser ha scritto: 
Hello,

PHP import_request_variables() arbitrary variable overwrite
 Date          &#-1;&#-1;   20060307
I believe all dates in the advisory contain the wrong year...

Oops..Yeh :) thank you, i'll change it on my site:)



III. ANALYSIS

import_request_variables() is not new to vulnerabilities: consider this
change log entry for 24 Nov 2005, PHP 5.1.

[quote]
- Fixed potential GLOBALS overwrite via import_request_variables() and
  possible crash and/or memory corruption. (Ilia)
[/quote]
  
Taking into account that the vulnerability you describe is fixed in
Hardened-PHP for years and that there is also a protection against this
in the Suhosin Extension you can be sure that this NOT a new
vulnerability (and that you are not the first one who found it...)


ok, this was the real timeline in my research:
day one:  
1. I see import_request_variables and read php manual.
2. I think about overwrite globals (no way).
3. I think about overwriting _SERVER and test it on php 5.1.6 
   (ubuntu)(it works!) 
4. I stop, gotta sleep.

day two: 
1. I search on google for import_request_variables advisories 
   (nothing found)
2. I search on php.net in changeLog for fixes (nothing found).
3. I download php 5.2.1
4. I test my poc on mod_php5 compiled from sources.
5. It works again.
6. Ascii and me write the advisory.

Sorry but  i used (maybe in a bad way) google and vendor site and in
some minutes i didn't find anything about the issue (apart from the 2005
changelog). And as no advisory where out on standard sites, I decided to
send my own research without any other effort knowing if it was known
publicly or in the wild.


I didn't look into other products like hardened php patch or suhosin,
cause they are not php by default.



For the record, the same vulnerability was reported by me on the
23.10.2004 at 22:05 in a mail to security () php net (before I added the
protection to Hardened-PHP)
At that time the PHP developers considered it NOT A VULNERABILITY.

Sadly enough i've also been told several times that some issue was not a
vulnerability, and later i found some advisory about that from other
researchers, so i can understand you are a bit sad...but we're both
professional and we do know these incidents are part of real world and
Full-Disclosure world.

Anyway it seems that your month of php bugs is getting php developers
more sensitive to all issues...
Maybe there was some misunderstanding between you and dev team and the
core team was less interested in this kind of flaws at that time.

Well now the PHP developers have commited a fix for this to the PHP CVS,
crediting you instead of the original reporter (me) 

If there are other credits to be given then let me say that i don't have write access to php.net site :).

and as usual the fix
is only fixing a part of the problem.
(Hint: long names like HTTP_POST_VARS do exist...)

did'nt see the fix, and so maybe you should add it to MOPB.

peace :),

Stefano

Stefan Esser
Hardened-PHP Project

-- 
...oOOo...oOOo....
Stefano Di Paola
Software & Security Engineer

Web: www.wisec.it
..................

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]