At 23:51 11-01-07, Stefan Esser wrote:
Zeev,
I don't know why you believe that I reported crash bugs. Yes of course
the local exploits I sent to [EMAIL PROTECTED] were only crashing PHP,
because they were 1-2-3 line Proof Of Concept Codes.
Except for one DOS only bug all the bugs can be exploited to execute
arbitrary code or access memory areas (read or write). And you will see
it in the Months of PHP bugs, when every released exploit will be
functional.
Let's not be nit picky with semantics, shall we? Most of the bugs
you reported are crash bugs which can be exploited to trigger
unexpected behavior. I'm not sure why you feel bad that I called
them crash bugs, but I don't mind - if you prefer me calling them
locally exploitable bugs I'm fine with that as well.
> After you left and started sending local exploits (with a few being
> remotely exploitable, but most of them not), I looked at it as some
> sort of a wakeup call. Not that they existed - it's pretty clear that a
Last time I checked a single remote exploit is enough to takeover the
PHP process.
The local vulnerabilities I sent are those that can be found from a very
quick audit and should be obvious to any security aware C programmer
(that knows a bit about the PHP source code). It is a pity that PHP
obviously lacks these kind of programmers. And it is a pretty good proof
that Coverity does not find anything of value.
No, you're wrong. It takes a long while to find some of them, just
as it took you. And even after your audit, I'm willing to bet
there'll be many other bugs you didn't pick up, because contrary to
what you say, it's not easy finding them at all.
As I said, PHP was never designed to be secure from malicious local
users, and the features that implied it was, like open_basedir and
safe_mode are a mistake on our part. By the way, 'our part' includes
you in this case - you were a part of the security team until a few
weeks ago, and I don't recall that you ever campaigned to remove
these features (forgive me if I'm wrong on that).
You want some more remote exploits. No problem. We have to wait a few
weeks or months until enough new lines of code have been commited and
there will be the next overflows. But considering how I was attacked
again today for telling Rasmus to tell the truth, I strongly believe
that a second Month of PHP Bugs should be sheduled for the future that
comes without any warning and shows your real performance. However it
was quite amazing that Andi shared his hallucinations about my quit
reasons with the world.
I actually find that very reassuring.
PHP has a *good* track record regarding remote exploits, it's
actually pretty amazing considering its popularity. I'm sure you've
done your best and will continue to do your best to point out any
remote exploits that you find, and the fact you can't find any
additional ones means PHP is in relatively good shape, and that the
sensitive parts are written by security conscious people, contrary to
what you say day in and day out.
I realize me saying that is going to motivate you even more to criss
cross PHP and look for remote bugs - and I'm fine with that. We'd
love to hear about them and fix them ASAP if & when you find any. No
remotely accessible software has a perfect track record, perhaps
other than qmail.
I hope you'd be professional about them as you were with the ones you
reported in the last few weeks.
Your personal insults against me, Andi, Rasmus and others don't
warrant a response so I won't get into them.
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
