TYPO3 Core

Should have said, that TYPO3_CONF_VARS['BE']['fileExtensions'] was not set in localconf.php!

Even worse:

I correct myself about the requirements (mod filelist enabled, file permissions ...).

The described attack works also for content element filelinks where you can either set a reference to a file kept in fileadmin area OR UPLOAD A FILE ON THE FLY.
The best thing is: In case of filelinks-element you even get a nice link in the FE to your malicious code file ;-)

To draw a conclusion:
You are vulnerable if
- there's at least one single Non-Admin BE-User who has (above mentioned) rights to filelist module
OR
- there's at least one single Non-Admin BE-User allowed to create content element filelinks.

A quick-fix would be modifying your vhost-configuration:

<Location /fileadmin>
<IfModule mod_php4.c>
php_admin_flag engine off
</IfModule>
<IfModule mod_php5.c>
php_admin_flag engine off
</IfModule>
</Location>
<Location /uploads>
<IfModule mod_php4.c>
php_admin_flag engine off
</IfModule>
<IfModule mod_php5.c>
php_admin_flag engine off
</IfModule>
</Location>

pretty simple solution would be to not allow files ending with this but not have .php at all in the filename then, right?

This looks like a major flow in PHP or Apache to me :(

we also stumbled that it is possible to execute any file
xyz.php.anyextension

This is a lack in Apache and there is a simple solution to avoid that:

<FilesMatch "\.php\..*">
ForceType text/plain
</FilesMatch>

Please consult the Apache docs. It's all written and explained there. But I have to admit that I wasn't aware of the fact.

http://httpd.apache.org/docs/2.2/mod/mod_mime.html#addhandler

The extension argument is case-insensitive and can be specified with or without a leading dot. Filenames may have multiple extensions and the extension argument will be compared against each of them.

http://httpd.apache.org/docs/2.2/mod/mod_mime.html#multipleext:

If you would prefer only the last dot-separated part of the filename to be mapped to a particular piece of meta-data, then do not use the Add* directives. For example, if you wish to have the file foo.html.cgi processed as a CGI script, but not the file bar.cgi.html, then instead of using AddHandler cgi-script .cgi, use
Configure handler based on final extension only

<FilesMatch \.cgi$>
SetHandler cgi-script
</FilesMatch>

Using this setup worked well for me:

<FilesMatch \.php⁴⁵?$>
SetHandler application/x-httpd-php
</FilesMatch>

My conclusion: do nothing, but add the tip to use SetHandler rather than AddHandler somewhere (?) in a "securing your installation" page.

User of Debian or Debian based distributions pay attention!

At least on Ubuntu Hardy Heron the suggestion of Martin does not work. Based on the fact that package apacheX-common depends on package mime-support and php mime types are then listed in /etc/mime.types, Apache is always aware of php mime types without setting handler for them explicitly.

Besides that it is not possible to unregister the handles by using RemoveType/RemoveHandler somewhere in apache.conf

I've filed a bug report regarding this issue at launchpad.net.

Solution is to comment/remove the php mime type entries in /etc/mime.types

Launchpad bugreport:
https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/225105

Issue resolved by TYPO3 releases 4.0.9, 4.1.7 and 4.2.1;
Security Bulletin issued: http://typo3.org/teams/security/security-bulletins/typo3-20080611-1/

Marcus Krause
TYPO3 Security Team

Issue resolved by TYPO3 releases 4.0.9, 4.1.7 and 4.2.1;
Security Bulletin issued: http://typo3.org/teams/security/security-bulletins/typo3-20080611-1/

Marcus Krause
TYPO3 Security Team