[/quote]
I can see why you weren't able to find anything. However, there have
been a number of disclosures that are probably related - but these
were grep-and-gripe affairs in third party applications, where the
researcher didn't necessarily investigate *why* certain attacks
worked.
[/quote]
let
Stefano Di Paola said:
1. I search on google for import_request_variables advisories
(nothing found)
2. I search on php.net in changeLog for fixes (nothing found).
I can see why you weren't able to find anything. However, there have
been a number of disclosures that are probably related - but
Hello,
PHP import_request_variables() arbitrary variable overwrite
Date 20060307
I believe all dates in the advisory contain the wrong year...
III. ANALYSIS
import_request_variables() is not new to vulnerabilities: consider this
change log entry for 24 Nov 2005, PHP 5.1.
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...
Stefan Esser wrote:
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...)
not
Hello Stefano,
first of all. I am not angry at you, although my mail might have sounded
so, but at the people that deserve it.
The fault of the PHP Security Response Team is not yours. They are the
ones that give credit to the wrong persons.
Luckily after 2.5 years they fixed that issue (or
