Stefan,
I'll concentrate on the technology aspect.
The situation in other languages has everything to do with PHP. It's
fine that you decided to concentrate in PHP, but the fact exactly the
same problem exists in other languages suggests it's an inherent
problem, and not something unique to PHP. In my opinion, it's also
something that cannot be solved. We can't treat hundreds of thousand
of lines of code, some of it generated code that we can't even fully
validate, as 100% security sensitive.
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 project the size of PHP contains crash bugs both in PHP's code
and 3rd party libraries that it uses, especially when you're
intentionally trying to use it in ways that it was not intended to be
used in order to crash it. The wakeup call was that we did not
sufficiently message the fact that languages cannot be trusted to
local users unless you use OS level protection a-la chroot/suexec or
a VPS, and PHP is certainly no exception.
There was a heated discussion about that topic in the security
mailing list, which at this point has not concluded in a meaningful
way. My take on this is that we should shout as much as we possibly
can - "DO NOT TRUST PHP (OR ANY OTHER LANGUAGE) TO LOCAL USERS
WITHOUT OS LEVEL PROTECTION". Protecting PHP from malicious local
hackers is futile, just as it is futile to protect any other language
from local exploits.
safe_mode, open_basedir and the likes are inherently flawed since
they protect at the wrong level. They cannot be fixed, they are
inherently prone to bugs - and every tiny bug immediately becomes a
security bug. disable_functions must also not be used as a security
feature but as an administrative feature, since again, a determined
hacker will always be able to find an exploitable crash bug. The
right solution is to deprecate safe_mode and open_basedir and make it
clear what the purpose of disable_function is.
To be clear, otherwise-local exploits which are very commonly found
in remotely-triggerable code should be considered as remote exploits
and dealt with quickly. To be also clear, we all value the work
you've been doing auditing PHP code.
I'd still like to grab a beer together with you in a couple of weeks'
time when I'm in Germany if you're around.
Zeev
At 22:20 11-01-07, Stefan Esser wrote:
Andi,
> Stefan, do you truly believe that other languages allow for
secure shared hosting without using a setuid or chroot solution? I mean
> take Ruby, Python, Java, C/C++. Can you point out one of them
which would not have the issues that PHP has? I think the problem in
>
How it the fitness of other languages relevant for the security holes in
PHP. What have other languages todo with the POOR quality of PHP's C
source code? Unlike other languages PHP claims to have functions like
disable_functions / open_basedir / safe_mode. They are however worth
NOTHING, because there are so many local vulnerabilities in PHP that
every attacker can just choose one and execute any code he wants anyway.
> Do we need to provide better tools for our developers?
Definitely! This is why we are working on ext/filter (I agree the first pass
> wasn't very successful), a filter extension in Zend Framework,
and other best practices.
>
Stop blaming PHP users. Of course a lot of them are not skilled and do
error. This is however completely unrelated to the POOR quality of PHP's
C source code.
> We have also made significant progress on the core PHP security
issues including a coverity code scan (and we are planning to use an
> additional company), removing flawed features such as
register_globals and safe_mode (the latter was never encouraged but I can't
>
You cannot achieve security with tools. Coverity has obviously not found
a single of the vulnerabilities I disclosed. They are worthless. You
cannot improve security with tools.
> blame people for falling into the trap with the crappy name), and
many other things. We also have had IBM Research look into various
> aspects of PHP one of these efforts led to Wietse Venema's
suggestion for tainting (which is the main reason why Stefan left the
> security team as he took that personally because a few years ago
he brought up the idea and we weren't in favor).
>
Andi your propaganda is getting old. First of all I never brought up the
taint mode idea. I simply started an implementation for HPHP and told
[EMAIL PROTECTED] that I think I should continue to work on it before you
have yours ready. The fact that someone brought it up in the past is
completely unrelated to me. The fact that I was immediately attacked by
Zend after telling [EMAIL PROTECTED] about this plan was just one more drop.
I left the PHP Security Response Team, because you do not listen,
because you think you know everything better, because you believe the
PHP community is full of security heroes. I had enough of this. I
strongly disagree and I see no reason to be part of a "security team"
that has actually no clue. And I also had enough from the countless
attacks from other PHP developers that want me dead, call me immoral
traitor, ...
> Stefan has a personal vandetta against the PHP Group because we
had asked him not to use the PHP brand in the Hardened-PHP patch.
>
Vendetta yourself. Unlike your silly accusations my vulnerability
reports are based on facts.
> PHP license does not allow it. We can not enforce that with
projects which are not directly derived from PHP's source code like PHP
> applications and groups, but Stefan considers we are still
following a double standard which we aren't.
>
You are following a double standard. A project that steals CSS source
code from the PHP source and uses it in a PHP application to mimic the
phpinfo() look has stolen code licensed under the PHP license. It cannot
have the name PHP in it's name. But we all know that Shiflett is your
close friend... Nothing more has to be said.
> I hope at some point Stefan is going to channel his knowledge in
a more positive way.
>
Andi grow up. Who do you want to trick with these closing words? A lot
of people know WHO improved the security of PHP during the last years.
If that is not a positive thing I really don't know.
Stefan Esser
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
