Description:
------------
Security when working with third parties became earn and dear after all my web 
sites were hacked wit virus inserting java ad-ware to all php ad html.
So these security bug reports are based on actual hacking that occurred.
I have several items below so as not to overwhelm the bug report system. 
And wile I consider any security hole to be a bug, you may well consider them to 
feature requests.

I hired a "reputable" web company highly rate on one of the largest free lance
Web programmer sites. Its certain they introduced the hack, but not certain if 
it was a company policy or a rogue employee. php is in the majority of web sites
that require any type of programming, and the majority of sites are built at 
least in part by third party programmers, employee or contractor. So it
is in all php programmers interests for php to retain a reputation as a safe 
language for web sites to use. 

I am willing to work on any of these patches myself, if they would be accepted 
functional changes. I would need a pointer to  modules to get started and 
someone willing to audit my patches, as there are no doubt subtle bits 
of internals I am unaware of. So by all means contact me if you want any of 
these items done by me.

Most of these are php.ini related.

I recently submitted a bug report that all include files are at risk because you 
cannot use include unless open_basedir also includes the include path. It 
occurred to me that include could probably accept files without a .php 
extension, like jpg, .mpg, etc or any binary file type not scanned.

One solution, php.ini have an "include_file_extensions" directive,
default to ".php", which prevents include from including file extensions
of apparently non php file types. It would be a list of file extensions.

==========

Hiding secure php.ini settings. 

php has for example a mysql.default_password,
which the comments say not to use because its insecure.
The only alternative is to give the 3rd party (employee or contractor) 
programmer the actual password, so there is no downside in using it,
but as the comments point out, not secure because its available
via environment.

Proposed solution, php.ini directive "private_php_directives"
default "mysql.default_password, mysql.default_user, open_basedir"
and perhaps a few more.

operation would prevent the listed directives from being exposed in environment
variables such as used in phpinfo.php

This one is huge, because it creates a secure way to allow third party 
developers to access mysql without ever being given even a temporary password.
============================
php.ini exposes file system structure outside the web site via environment 
variables, and error messages expose this as well. On unix, the user id 
is one of the folder names o the path, and on Panel, the unix login
is used, so the path effectively exposes the cPanel login, allowing for 
exhaustive password attack. Even if the system blocks the attack, 
exhaustive password attack is also effectively a denial of service 
attack, by swamping the server. 
Best not to invite the attack by exposing the user id.

proposed solution #1, 
php.ini directive "hide_path_roots", default "on".
All printed folder paths will be truncated at root.
file system operations will show paths relative to open_basedir path(s)
php error messages and php environment variables 
(as accessed by phpinfo for example)
will show paths relative to document_root(s) or include_path(s)

if set, "document_root" would be shown by phpinfo.php as "." or "".
ditto for open_basedir and include_path, as the point is to hide these
from 3rd party programmers.

proposed solution #2, sinpler but a bigger hammer
php.ini directive "suppress_paths" default "on"

Differences - now prints as
  <document_root>/subdir/file.php
proposal 1 prints as 
  /subdir/file.php
proposal 2 prints as
  file.php

Either proposal allows web site owner/admin to select the current behavior.
========================================

"mysql" script security

One of the multiple ways my site was hacked, was via mysql data.
It was based on osCommerce, which includes all text from mysql for language
support. The attach was to place hidden java ad scripts inside mysql data.
Now unmodified, osCommerce may filter these now, but using a 3rd party
the filter can easily be deleted, since osCommerce and all php packages 
(joomla and dozens of others) currently run as user's files, 
not protected "execute only" system files 
(which is a design flaw on their part)

One solution would be to have a setting prohibiting java scripts, and/or html 
tags from appearing in mysql data or perhaps just character data.

The php solution is to strip_tags() i believe, but the point is for settings
preventing the programmer from classes of misbehaving.

I don't have a clean proposal for this one, just advising you it is a
current hacking practice to place virus code in mysql, which defeats 
file system virus scanners.
======================================

I applaud removal of "safe mode". Although I need secure operations, I had
no idea what it really did, so never used it.

Still some broader switches would be helpful. 
using disable_functions to turn off file system requires listing hundred+ 
functions, and i probably missed some. Ditto for smaller number of
functions to disable direct execution in the underlying OS
(which by the way bypass open_basedir)

proposed solution:
disable_functions accept some tokens for sets of functions
[filesystem] [shellexecute]
It makes a more readable and manageable php.ini, 
Also, an exhaustive list is vulnerable to becoming out of date
each time a new function is added.

Alternatively, these tokens could be treated as pseudo classes by
disable_classes directive 
or a new directive for disabling types of functions added.


Test script:
---------------
phpinfo.sql exposes passwords, user ids for mysql and unix cPanel login.
(alternative is to give away the password and user for mysql, even worse)

Any error which prints php file path exposes unix cPanel userid

any script placing data from mysql into html stream exposes 
stream to java ad scripts in mysql data

Its not possible to use php.ini to prohibit file system access,
as any exhaustive file system function list will become out of date
if any new file system function is added.
Ditto for shell execute functions, or other os function classes.

"include <anyfilename>.jpg" exposes php to potentially un-scanned file.

any shell execute function can run "rm ~/* ~/*/*" etc, no matterwhat open_basedir is set to.

Expected result:
----------------
To be ale to set php.ini or php environment up so that
user ids, passwords may be kept confidential from 
employee/contractor php programmers.

to prevent include from including "data files" as php

to prevent file system fnctions from accessing php scripts as (read/write) data 
files.

to prevent system shell execute functions from bypassing open_basedir protection


Actual result:
--------------
same as test script examples.