bugtraq - Re: [Full-disclosure] PHP import_request_variables() arbitrary variable overwrite

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Sat, 10 Mar 2007 18:05:43 +0100
From: ascii <ascii@...amail.com>
To: Stefan Esser <sesser@...dened-php.net>
Cc: bugtraq@...urityfocus.com,
	Stefano Di Paola <stefano.dipaola@...ec.it>,
	full-disclosure@...ts.grok.org.uk
Subject: Re: [Full-disclosure] PHP import_request_variables() arbitrary variable
 overwrite

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 being credited is really annoying and i understand your feelings but
it happens, take a look here, this vulnerability was fixed 3, 4 times?
http://www.ush.it/2006/01/25/php5-globals-vulnerability/

i'm sure i wasn't credited at all but who cares, i just want the bugs
fixed, and i think that this is the spirit of this month

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

some misunderstanding in the communication between you and php team? it
happens and i'm sad for it but this is not our fault

fun
on 21.10.2004 at 20:12 i called my grandmother but she was sleeping, she
is an old lady and it's normal to fall asleep at that age : )
/fun

i think that it's possible that your month of php bugs could have
changed the way php devs look to vulnerabilities (if so the goal is
fully reached) or it could be the full disclosure

i mean: why don't publish something you found in 2004? just post an
advisory of the type "i found this, they said NO-NO, this is the bug,
use my products to get protection"

> Well now the PHP developers have commited a fix for this to the PHP CVS,
> crediting you instead of the original reporter (me) and as usual the fix
> is only fixing a part of the problem.

umh.. next time publish your findings : ) you will get credit from the
beginning and the bug will be fixed

my feeling is that it's important to fix software, any way is allowed:
if internal disclosure doesn't work i'll post to fd, or post directly
to fd

and while your products are valid and i personally use them my guess is
that it's more important to fix things in php itself as from the
statement you made "initiative to improve PHP's security"

if there are other things in your products that are not fixed in php why
don't publish them?

> (Hint: long names like HTTP_POST_VARS do exist...)

the just fixed _POST and so on? nice : )

i really appreciate your work with php, keep up with the disclosure!

Regards,
Francesco 'ascii' Ongaro
http://www.ush.it/

ps: add some smiles in your mails or people will get confused about the
tone of your speaking : )