Our web hosting service shut down the Oz Report web site because
some malicious person or entity had used one of our scripts to send out devious
material. Pair.com tracked it and took us off line.

Scare got on the case and finally tracked down the vulnerability. So we are back
in business. For those interested, here are the technical details:

I've fixed that vulnerability. It turns out that a superglobal
variable, which the web server supplies to the PHP interpreter which may then be
accessed by PHP scripts, and is supposed to contain the filename of the
currently executing script, will also include the rest of the malformed request
if it continues after the script filename with an immediate "/". In the case
here, that stuff was included into the environment that was evaluating which of
our advertisements should be displayed on that page, and since it was inside
double-quotes, variable substitution was done for a part of the request,
resulting in the included command being executed by PHP.

I've prevented this exploit from working by doing the following:

- the contents of the supergobal variable is sanitized before use, to include
only the filename

- the filename environment variable is single-quoted (no variable substitution)

- the access file routes any request similar to those into a dead-end script
which does nothing but add a "deny" rule for that address