Note that the bug is against a platform we strongly advise against using
in any sort of production environment. Not that we shouldn't fix it if
anybody can reproduce it (which I haven't heard anybody say they could),
but there is a reason we are still telling people not to use Apache2+PHP
in produ
usually people with some responsibility in mind won't disclose a bug that
might cause system to be penetrated, before the vendor had enough time to
respond with an answer to the bug. if the bug he found might be a bug that
would result in every server running PHP to be cracked, that's not good.
On Thu, 26 Jun 2003, moshe doron wrote:
>
> > limited, so before a check, every segfault *might* have security issues
> > behind...
>
> in the bottom line, there were, there'll and probably there are
> such "security issues" where the dealing is publicly/ in
> contrary there was in the past file u
> limited, so before a check, every segfault *might* have security issues
> behind...
in the bottom line, there were, there'll and probably there are such "security issues"
where the dealing is publicly/
in contrary there was in the past file uploading issue that cause to role pl. where is
the
every program that crashes due to overwriting of memory it should not
overwrite is subject to overwrite the registers that control the flow of
the program, and might, upon user input, execute arbitrary code. the real
question is how much can you effect the flow of the program - that depends
on
ummp, sorry for my ignorant, when segfualt consider as "potential security
report"?
i put similar (?) example in the past on the bugs.php.net that's live there
open about 2 month's till wez fix it, without considering the last sascha
integer overflow hunting project...
--
moshe
"Simon Ejsing" <[
