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
