On Fri, 2006-08-18 at 23:24 -0700, Steve Langasek wrote:
> Should this bug really be considered "grave"? Is there a valid reason why
> the exec'ed scripts should be printing to stderr, or could this be equally
> considered a bug in those scripts?
Data written by CGI scripts to stderr is logged by the web
server--apache puts it in a site's ErrorLog. Since most PHP scripts are
badly written, they generate many many many errors when run with the
recommended PHP configuration; large scripts overflow the 4096 byte
limit. This happens all the time with our Joomla (a very popular content
management system) sites.
When the same issue cropped up in Apache itself[0], the developers
didn't consider it very important. However the bug is a local DOS attack
as it lets a malicious or compromised user grind the web server to a
complete halt. This renders the package unusable from the point of view
of an administrator for a large, shared web server, where the package
would be installed to prevent users from trying to bring down the
server.
[0] http://issues.apache.org/bugzilla/show_bug.cgi?id=22030
However, the package is still useful on smaller servers where users can
be trusted. In addition, I think most admins realise by now that
securing a machine running any form of PHP is basically impossible. So I
won't object if the package maintainer or the release team don't
consider this a critical issue. Short of an actual fix (given the time
since the last release, upstream may even be dead) then I think adding a
large, flashing warning to the package's README.Debian will settle the
issue.
I actually started work on a workaround in the form of a filter that
passes through data on stdin and stdout, but limits the data from stderr
to 4096 bytes, but I've only got lots of deadlocks so far. :(
--
Sam Morris
http://robots.org.uk/
PGP key id 1024D/5EA01078
3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078
signature.asc
Description: This is a digitally signed message part
