Message-Id: <1173542766.7614.62.camel@laptop>
Date: Sat, 10 Mar 2007 17:06:06 +0100
From: Stefano Di Paola <stefano.dipaola@...ec.it>
To: Stefan Esser <sesser@...dened-php.net>
Cc: phpsec <security@....net>, FD <full-disclosure@...ts.grok.org.uk>,
	bugtraq@...urityfocus.com
Subject: Re: PHP import_request_variables()
	arbitrary	variable overwrite

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@....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/

Powered by blists - more mailing lists