[ale] Seven Deadly Sins - PHP

[J.M. Taylor]

I keep posting here because I have administered boxen running PHP, and
programmed with PHP, for the last 4 years.  I'm sure at this point I'm
just talking to hear myself, but Bob has raise a very critical question
that's bothered me as a systems admin and a programmer, and I think it
bears discussion.

> My guess is that it is
> more secure than  running telnet - if not, let's make an "ssh" of PHP.

There are always ways a stupid or malicious programmer can thwart the
securing of the interpreter.  PHP > 4.2x in and of itself, as an
interpreter, is more or less stable and secure.  Like gcc. Or javac. Just
having the PHP interpreter on your server (assuming you know 100% that you
control every file on that server) is a significantly lesser risk than, as
you said, running Telent.  It doesn't listen for remote connections. It's
not a service.  And its default configuration is more secure now; it's
more about educating sys admins that PHP's interpreter *can* be secured,
versus needing changes to the underlying code.

HOWEVER. Every PHP (and other cgi-executable) script can be thought of as
a new network socket, listening and waiting for the outside world to give
it instructions.  Conceptually, having an executable program on the web is
no different than running telnet or FTP -- an outside person can use it to
request that your server do something.  Now, if you don't know *exactly*
what that code is doing, whether it's telnet or a PHP program, it's
dangerous.

> Bob has
> explained  to me why we should "not use" messenging programs. (GAIM,
> YMessenger, MSN  Messenger, etc) and clear explanations can be offered
> for the statement  "don't use" telnet.  OT, what about Unreal
> Tournament/online gaming? :)
>
> The question is: Does PHP fall in the same catagory?

As a paranoid person, I say again, yes.  Using *any piece of software that
you did not write and have audited by someone else* is dangerous.  I
certainly did not write the PHP interpreter, nor did I write Apache, BIND,
Cyrus, or any of the other software I have run in the past.  Come to that,
I did not write the linux kernel, nor would I know what the hell I was
looking at were I to look at the source code. I trust the community to
protect me from flaws, and that's the strength of open source -- if
there's a problem, *somebody* will find it.  The key is if the good guys
find it first. :)

The number of eyeballs that can be devoted to PHP programs, which even the
totally ignorant can download and install on a web server (and the mostly
ignorant, not to mention malicious, can write and post for downloading),
are significantly less than are devoted to Apache. Installing a PHP script
is usually much easier than a perl cgi, because PHP runs inline with HTML.
The perl cgi can be just as dangerous, but the demographic of people
installing it is different than PHP.

The chances of someone who *really* knows how to write secure network
applications writing or auditing PHP applications is extraordinarily slim.
 Would you let your users download tftp and install it wherever they
wanted??  Would you, as an admin, install NFS and not lock it down?  The
concepts are the same.

Instant messaging is a really good example.  The security model is
horrific, and no, nobody in their right mind would use it.  Do I use it?
Yes, all the time.  Do I pass ANY sensitive information over it? Hell no.
You don't walk up to a snake, poke it with a stick, and hope it doesn't
bite you, and hope it's not poisonous if it does.  Installing software on
a networked machine is the snake -- if you can't identify the snake
(phpWidget), consult your field guide (google, Bob, SecurityFocus,
Xcorps), and if you still don't see it, stay really far away from it.  If
you're forced to touch it, wear heavy gloves.  Even if you can identify
it, it's a good idea to double-check before you walk past it, and it's
never a good idea to poke it with a stick.

Now. That said, Bob is a security consultant. He gets paid to say things
like "This is bad, and this is too dangerous to run. X, Y, and Z are risks
you run if you do this."  He has to know how to look at a staggering range
of software and network topolgy and operating systems and business
organizations and evaluate the risks in the combinations thereof.  He also
has to be able to suggest workable alternatives (use ssh instead of
telnet).

I am a systems administrator. I get paid to do insane things like run PHP
applications on a web server where people have FTP accounts (ie, I don't
control the files that come onto the box).  I read Bob's books, articles,
and ALE posts because I value his knowledge and experience.  Then it's my
job to take what he says, and find out how to make it fit the real world
that I live in.  I have to know and understand the risks, and figure out
how to mitigate them when I have to break his rules.  I also have to know
how to be alert for someone taking advantage of the risks he has pointed
out, how to judge what is an acceptable level of security for a given
machine and the role that machine has in my organization.  I have to know
how to take the instructions that come from the Suits and implement them
in the way that is least likely to result in a breach of security, without
inconveniencing the users, and without getting me fired. In my spare time,
I write lengthy emails detailing my quandary when Bob's advice conflicts
with what I have to do.

I do take exception to Bob singling out PHP, as I'm sure I would if I had
invested as much time in Perl and he said "Don't run Perl on your server".
My long and rambling posts happen when good, correct advice conflicts with
what I still have to do regardless of that good, correct advice.

Sorry for the book. Happy to take this off-list or onto betterphp.org
(since nobody posts there anyway :P ) if anyone wants to make it go away.

jenn


_______________________________________________
Ale mailing list
Ale at ale.org
http://www.ale.org/mailman/listinfo/ale