Re: PHP 4, 5, or neither?

Clever Monkey <clvrmnky.invalid@xxxxxxxxxxxxxxxxxxx> wrote:
dave wrote:
Clever Monkey <clvrmnky.invalid@xxxxxxxxxxxxxxxxxxx> wrote:
dave wrote:
Joachim Schipper <joachim@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
dave <daf@xxxxxxxxxxxxxxx> wrote:
The web app that I'm interested in is Zoneminder, a comprehensive
video security application. Zoneminder uses both mysql and php,
either 4 or 5. I am not eager to install php. I am considering the
alternative of building my own much simpler video security
application using videod, fwtv and scripting tools.
This is a serious question: how do you know your home-made solution
would not have holes of its own? The Intertubes are littered with the
dead bodies of home-grown projects that were considered safe before
falling apart. Security is hard to get right.

There are hardened PHP5 packages that go through some source-level
auditing, and include all known security issues of merit. These also
get updated as the package maintainer folds solutions to newly
discovered security problems into the package.

As suggested else-thread, you must assess, first, what your threat
profile is. How available is this service, and to whom?

It's available to me when I activate it.

Is this who you want it available to, or is it also available to others?

If this service is on your net but is accessible by the internet at
large, then you have made that service "available" to everyone here.

If this is a web service, then you have to consider what other
user-agents, and from where, might have access to the service. This is
the first level of the threat consideration.

i.e., Who has access?

Then you have to determine the vectors of attack those connections can
leverage to subvert your service.

i.e., What can these people do with this access.

The answers to this last question can be many and complicated. Start by
answering the first one _properly_ first to determine the scope of the
second question.

Just as a suggestion: enable proper, IP-level (pf) security, and don't
use the webserver on the box for anything else (for added paranoia,
don't use any part of the box for anything else, and don't connect it to
any network - this is highly dependent on just how hard it is to get
at all your camera data, and how much you'd care if someone did).

This way, PHP's usual security issues and any bugs in the application
won't matter all that much. Of course, it will be somewhat inconvenient.

Joachim
.

Relevant Pages

  • TSLSA-2005-0059 - multi
    ... Affected versions: Trustix Secure Linux 2.2 ... PHP is an HTML-embedded scripting language. ... use of Rest with FTP servers and Range with HTTP servers to retrieve files ... - New Upstream and Multiple Vendor Security Fixes ...
    (Bugtraq)
  • [NEWS] PHP Security Vulnerability in Multipart FORM Data Handling
    ... The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com ... The PHP Group has learned of a serious security vulnerability in PHP ... code with the privileges of the web server. ...
    (Securiteam)
  • TSLSA-2007-0017 - multi
    ... Affected versions: Trustix Secure Linux 2.2 ... PHP is an HTML-embedded scripting language. ... SECURITY Fix: Arnaud Giersch has reported a weakness in ELinks, ... The Common Vulnerabilities and Exposures project ...
    (Bugtraq)
  • Re: Securing an Email script
    ... request to our sales office. ... Since you do ZERO checking on the values it's nothing BUT security issues. ... very powerful PHP function to validate form fields and other strings - ...
    (comp.lang.php)
  • [ GLSA 200511-08 ] PHP: Multiple vulnerabilities
    ... PHP suffers from multiple issues, resulting in security functions ... bypass, local Denial of service, cross-site scripting or PHP variables ...
    (Bugtraq)