Posted by Rory Browne on 08/26/05 15:42

Santosh:
Personally what I think you did wrong, was to simply paste the header
of that news article into your email. You simply said that PHP was hit
by another security hole, that allowed crackers(sometimes incorrectly
refered to as hackers), to gain access to any php service. I don't
think you would have been attacked if you simply refered to some
article said php was insecure, saying "This article says php is
insecure". You seemed to be saying yourself that "PHP was insecure",
and backing it up using that article.

I think at this stage a bit of background in computer security is in
order. There is no computer that is 100% secure. Even a computer that
is buried 5 miles beneth a heavly guarded army base with no power or
communicaton cables can be penetrated by the right person/people.

In the same way nearly all software, including PHP has bugs. The
difference with free/libre/open source software, is that any security
critical bugs, are fixed within an extremely short timeframe, and so
long as you update your machine regularly with any security related
updates, you should be OK.

This applies to all software of course, but the difference between
PHP, and other other propriatory solutions is that security updates
are released very soon after they are found.

Ian:
The department is right. PHP is a security risk. So is every other
piece of software on your machine. What your department has to do is
manage that risk. The default way of installing PHP will allow users
on a shared server to execute commands under the web-servers UID. This
can be, to a certain extent prevented using safe-mode, or better
again, using something like suExec/suPHP (search google or apache
docs).

PHP is like any other server application. You need to decide what
compromise between usability and security you want to make. You
basicly want to make it as secure as possible, without sacrificing any
essencial usability.

As an example, disabling register_globals makes your script more
secure, but you have to use $_GET['varname'] instead of $varname. That
is IMO a usability sacrifice well worth making in the interest of
security.

You'll find plenty more security related articles on the net, as to
how you can minimise the insecurity caused by PHP.

On 8/25/05, Santosh Jambhlikar <santosh.jambhlikar@cash-tech.com> wrote:
> As this is the php mailing list it is obvious that i should not write
> against php. but people should know the truth. And it's a news (not by
> me) that's why i wanted to send link to u peoples.
> I am sorry if i did something wrong, i am new user in php mailing list.
>
>
> Jasper Bryant-Greene wrote:
>
> > Santosh Jambhlikar wrote:
> >
> >> also
> >>
> >> PHP HIT BY ANOTHER CRITICAL FLAW
> >>
> >> A new security flaw in the PHP Web service protocol used by a large
> >> number of Web applications could allow attackers to take control of
> >> vulnerable servers.
> >> http://www.computerworld.com/securitytopics/security/holes/story/0,10801,104124,00.html
> >
> >
> >
> > You are spreading FUD about PHP. Stop it. If you actually *read* the
> > article carefully you will find that not only is this not a PHP bug,
> > but a bug with two XMLRPC libraries written *for* PHP. Not PHP itself.
> > This is completely irrelevant to the original topic, as I didn't see
> > the OP asking for XMLRPC security advice.
> >
> > While you're at it, why not publish an article "PHP HIT BY ANOTHER
> > CRITICAL FLAW" with the text "A new security flaw in my website, which
> > is developed using PHP, surfaced today..."
> >
> > Jasper
> >
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

[Back to original message]