[Product Description]
"AWStats is a free powerful tool that generates advanced web, ftp or mail server statistics, graphically.
This log analyzer works as a CGI or from command line and shows you all possible information your log contains,
in few graphical web pages".
Current stable version: AWStats 6.3 final
Development version is 6.4 - 2005-02-06 14:31

[Summary]
Successful exploitation of an input validation vulnerability in AWStats scripts
allows attackers to execute limited perl directives under the privileges of
the web server, get sensetive information.
Some actions of the attacker can lead to denial of service.

[Details]
Some AWStats's functions can be extended with plugins.
Two variables (loadplugin & pluginmode) are dealing with it.
The first one (loadplugin) is responsible for plugins list (plugin1, plugin2); the second one
runs plugin's functions.

Deletes everything but '_', '-', '\', '/', '.', ':' and any blank symbol.
It's enough for variables with path to configuration files, but not for plugin tasks.
In case of "loadplugin" & "pluginmode" developers obviously have a lot of trust to the user.

If variable exists, we'll get code execution. This happens after sanitizing (see privious).
Here we have intresting part in:
my $function="BuildFullHTMLOutput_$PluginMode()";
eval("$function");

This is subroutine call (As example sub BuildFullHTMLOutput_rawlog() from
rawlog.pm plugin).
Ideal case: "module name"::BuildFullHTMLOutput_"function name"().
But if we won't specify the name of module (with "loadplugin" parameter) we'll get the next:

main::BuildFullHTMLOutput_"function name"().

By the way, there is permited symbol ':' in user input parameters. So, we can send:

PluginMode=:print+getpwent

And the $function becomes 'BuildFullHTMLOutput_:print getpwent()'.
This will satisfy eval() requirements., and :print getpwent() is executed.