>> a recent post on bugtraq hilighted an issue with how upstream has >> configured apache to invoke php, namely using addhandler, which has the >> behavior of matching the extension anywhere in the file. this means >> that foo.php.jpg will be run as php. where this becomes an issue is web >> apps that allow uploads into the webspace for images, pdfs, etc. if the >> app assumes that anything.jpg is safe, this addhandler feature will >> surprise it. > > Hi Joe, > > Are you sure this is limited to just CentOS? I've seen that config > used before on other distro's apache configs. i'm sure other distros use the same method, but i don't use any and this is the centos list, so that's all i'm talking about. > >> From the Apache 2.x Docs: > > --- > Care should be taken when a file with multiple extensions gets > associated with both a MIME-type and a handler. This will usually > result in the request being by the module associated with the handler. > For example, if the .imap extension is mapped to the handler > imap-file (from mod_imap) and the .html extension is mapped to the > MIME-type text/html, then the file world.imap.html will be associated > with both the imap-file handler and text/html MIME-type. When it is > processed, the imap-file handler will be used, and so it will be > treated as a mod_imap imagemap file. > --- > > So if example.php.gif is read by apache, the AddHandler for > php5-script (mod_php) will take precedence over the mime-type handler > for .gif (image/gif) and the file will be treated as a php script. > >> From that it almost sounds like it's not a bug, just apache's own > rules of precedence for handling files that match multiple > extensions/mime-types. i can understand why apache has this behaviour, but i think the bug is using it for handlers that can execute code. since the expected behaviour can be obtained more safely with the filesmatch mechanism, it sure seems like an obvious change.