Fwd: packages: php/php-mod_php.conf - match only *.php for added security by avo...

Tomasz Pala gotar at polanet.pl
Mon May 4 20:31:13 CEST 2009


On Mon, May 04, 2009 at 15:43:54 +0200, Patryk Zawadzki wrote:

> Actually here it seems to be more secure the other way around - not
> alowing parsing of uploaded foo.php.jpg files for example (at least
> some webapps only care about file extensions).

I know only one application having direct web access to uploaded data:
coppermine-gallery (Alias /cpg/albums /var/lib/coppermine-gallery/albums)

I've created index.php.jpg and the file was fetched (not parsed and
executed) - that's probably due to registered mime-type. Conclusion #1:
- if webapp cares about file extension, nothing bad should happen.

OK, let's assume our webapp doesn't check anything: mv index.php.jp{g,}
Now the Bad File indeed is executed. Let's try to fix our webapp:

http://cvs.pld-linux.org/cgi-bin/cvsweb/packages/coppermine-gallery/coppermine-gallery-apache.conf?r1=1.4&r2=1.5

tadam. I think that's the way upload dirs should be protected.

Maybe we should globally disable PHP for entire /tmp and /var? Is there
any code that should be run from within these locations?

> To exploit .rpmsave, you need to a) know it's PLD, b) know the config
> copy is in the DocumentRoot (packaging bug). YMMV but most likely you
> won't get a chance to execute any code.

Someone gets a chance to made database passwords public (I do clean them).

> To exploit .php.foo you can ask google for a list of sites using the
> same software (for example querying for "powered by foo") and do a
> mass scripted exploit. This allows people to run untrusted code on
> your webserver.

I'm aware of such threat, but I'm not sure this is the proper solution
(without some filtering).

-- 
Tomasz Pala <gotar at pld-linux.org>


More information about the pld-devel-en mailing list