RE: phpBB Worm

From: Ofer Shezaf (
Date: 12/23/04

  • Next message: Boren, Rich (SSRT): "[ Security Bulletin ] SSRT4699 rev.0 HP-UX SAM local privilege increase"
    Date: Thu, 23 Dec 2004 15:28:11 -0500
    To: "Anders Henke" <>, <>

    Interestingly enough the worm was probably developed on *nix and than
    checked and corrected to work on Windows:

                    while(my @a = getpwent()) { push(@dirs, $a[7]);}

            push(@dirs, '/ ');

    the getpwent function is not supported on Windows. Actually the entire
    loop that gets users home directories from the /etc/passwd file is very
    *nix centric.

    The author found that out, added the eval statement to prevent the
    script from crashing on Windows and added the root directory in order to
    have at least one entry on windows. This last line actually makes the
    entire loop less important.

    Additionally, on Windows the worm would affect files on a single disk.
    As to which disk exactly, it probably depends on the web server
    attacked, and how PHP and Perl are installed and used with the web
    server. In some cases, if the web sites and the software do not reside
    on the same disk, the worm payload will not work.

    Ofer Shezaf, CTO
    Breach Security, Inc.
    Deployable Application Security

    Tel: +972.9.956.0036 ext.212
    Cell: +972.54.443.1119

    -----Original Message-----
    From: Anders Henke []
    Sent: Thursday, December 23, 2004 2:31 PM
    Subject: Re: phpBB Worm

    On Dec 22nd 2004, wrote:
    > 1. Why has the worm been as effective on Windows servers as on *nix
    servers? At the very least, shouldn't the difference in file and
    directory naming cause a problem? I looked at the decoded Perl script,
    but I'm not a Perl expert, so I couldn't understand all of it. And what
    about the difference in file permissions?

    Perl does provide cross-platform-functions for e.g. file access and
    there's usually not much of a difference for running a well-written
    perl script on Unix as well as on Windows other than the first line
    (usually '#!c:\perl\perl.exe -w' on Windows and '#! /usr/bin/perl -w'
    on Unix).

    However, most Windows-Webservers other than Apache do run any .pl-Script

    using the to-be-installed perl interpreter and don't care on the

    The documentation found in 'perldoc perlport' does give a closer view
    on the few differences when writing cross-plattform perl scripts.

    > 2. More importantly, why wasn't the worm's destructive ability
    limited by file permissions, especially on *nix servers? If, for
    example, an HTML file on the server was uploaded by user bob, and has
    permissions of 755, how can the Perl script delete that file? Shouldn't
    the Perl script be created with the Perl process's permissions, which
    was invoked by PHP, which should have the Web server's permissions,
    which should be, at least on most *nix servers, the nobody user?

    On shared servers with ISPs caring about security, user CGIs are using
    suexec mechanism in order to run each customer within his own user's

    The downside of using suexec is that PHP as a CGI doesn't offer a small
    number of special features some people do believe to be essential, as
    as some people do write code in a way that making it work on PHP as CGI
    is close to 'virtually impossible'. The PHP-Module also allows one to
    set PHP-configuration settings via .htaccess; those configuration
    changes are also ignored by CGI-PHP and can severely affect the way
    an PHP-written application works (or doesn't work).

    > This is a big issue on shared servers, or virtual hosts, whatever you
    want to call them. Our site is on a shared server, and our site does
    not even run phpBB, but most of our HTML files were replaced with the
    worm's content. Obviously, then, another site on the server must have
    an old version of phpBB. But why could the worm, coming in through
    another site, modify files created by other users? Even if the worm's
    script ran as the owner of the vulnerable viewtopic.php file, how could
    it then modify non-world-writable files created by other users?

    Right - if everyone were using e.g. suexec, this would be the case.

    As a web host, you've got to chose to run either CGI-PHP or PHP as

    Your 'power'-users are calling for the module, the admin keeping
    maintenance on an already overloaded server does also all for the module

    (the module relieves the web server from forking a seperate process for
    running a php-script), only those security-related ones are rejecting
    mod_perl as well as mod_php and favour 'true' CGIs via suexec.

    If your scripts support the fastcgi extension, one might use mod_fastcgi

    with suexec support; however, this means one has to setup three
    (fastcgi, suexec, php) and make them work together instead of the
    often-recommended 'add mod_php'-Oneliner. As a result, you're spending
    much work on a secure system, but your users are still calling for
    and in case any part of your setup breaks, your whole system is

    > I have long been concerned with the security of PHP scripts,
    especially on shared servers. Since PHP almost always runs as an Apache
    module, and Apache usually runs as nobody, one must make files and
    directories world-writable for PHP scripts to be able to write to them.
    But that means that any process on the server, including anyone's PHP
    script, can modify the files.

    Yes, you've got the point.

    Apache 2 has the ability to run modules per VirtualHost within a
    user context (perchild MPM).
    -According to the Apache documentation, this module is non-functional,
     not yet finished and development is not currently active.
    -PHP is certainly one of the most interesting modules for this feature,
     however, the last time I looked, exactly PHP didn't support it and
     required to have at least one process running per virtualhost (which in

     turn would render servers hosting thousands of sites unusable).
    -Still today, the php documentation warns from using Apache 2.0 with PHP

     in productive environment.

    From a security aspect, the only way for running PHP securely
    (with 'secure' from the view of the administrator), CGI is currently
    the only way to do so.



    Schlund + Partner AG              Security and System Administration
    Brauerstrasse 48                  v://49.721.91374.50
    D-76135 Karlsruhe                 f://49.721.91374.225

  • Next message: Boren, Rich (SSRT): "[ Security Bulletin ] SSRT4699 rev.0 HP-UX SAM local privilege increase"