Home    |    View Topics    |    Search    |    Contact Us    |   



Category:   Application (Forum/Board/Portal)  >   PunBB Vendors:
PunBB Input Validation Flaws Let Remote Users Inject SQL Commands and Include File Bug Lets Remote Users Execute Arbitrary Code
SecurityTracker Alert ID:  1017131
SecurityTracker URL:
CVE Reference:   CVE-2006-5735, CVE-2006-5736, CVE-2006-5737   (Links to External Site)
Updated:  Jun 3 2008
Original Entry Date:  Oct 30 2006
Impact:   Disclosure of system information, Disclosure of user information, Execution of arbitrary code via network, User access via network
Fix Available:  Yes  Vendor Confirmed:  Yes  Exploit Included:  Yes  
Version(s): 1.2.13 and prior versions
Description:   Nms reported two vulnerabilities in PunBB. A remote user can include and execute PHP code located on the target system. A remote user can inject SQL commands.

The search module does not properly initialize the $result_list array. If register_globals is enabled, a remote user can supply a specially crafted parameter value to execute SQL commands on the underlying database by exploiting the PHP Zend_Hash_Del_Key_Or_Index vulnerability (on affected versions of PHP; 4.4.2 and prior, and 5.1.3 and prior).

A demonstration exploit request is provided:

&result_list[< UNION SQL QUERY >/*]&1763905137=1&1121320991=1

The software does not properly validate user-supplied input in the pun_user['language'] parameter. A remote user can supply a specially crafted URL to cause the target system to include and execute PHP code from a file on the target system. The PHP code, including operating system commands, will run with the privileges of the target web service.

The original advisory is available at:

Impact:   A remote user can execute PHP code located on the target system with the privileges of the target web service.

A remote user can execute SQL commands on the underlying database.

Solution:   The vendor has issued a fixed version (1.2.14), available at:

Vendor URL: (Links to External Site)
Cause:   Input validation error, State error
Underlying OS:  Linux (Any), UNIX (Any), Windows (Any)

Message History:   None.

 Source Message Contents

Subject:  Punbb <= 1.2.13 Multiple Vulnerabilities

Hash: SHA1
- -= PunBB <= 1.2.13 Multiple Vulnerabilities =-  

Written on :                 2006/10/10
Released on :                2006/10/29
Author :                     Nms < nms (at) wargan (dot) org >
Affected application :       PunBB <= 1.2.13
Type of vulnerability :      SQL Injection and Local File Inclusion
Required PHP Configuration : Register_globals enabled, PHP <= 4.4.2
                             or PHP <= 5.1.3 for the SQL Injection,
                             none for the Local File Inclusion
Evaluated Risk :             Critical
Solution Status :            A new version (PunBB 1.2.14) has been
                             released which fixes these vulnerabilities
References :       

[0] Application description
    From :
    "PunBB is a fast and lightweight PHP powered discussion board.
    It is released under the GNU Public License. Its primary goal
    is to be a faster, smaller and less graphic alternative to
    otherwise excellent discussion boards such as phpBB, Invision
    Power Board or vBulletin. PunBB has fewer features than many
    other discussion boards, but is generally faster and outputs
    smaller pages."

[I] SQL Injection Vulnerability

 1) Overview

    PunBB is prone to an SQL injection in the search module,
    because of an unitialized variable which is undirectly passed
    into an SQL query without any check. Using this vulnerability,
    a visitor can perform blind SQL injections, which can lead to
    the content disclosure of any data stored in the database. The
    exploitation of this flaw uses the PHP Zend_Hash_Del_Key_Or_Index
    vulnerability, and thus requires register_globals enabled and
    PHP <= 4.4.2 or PHP <= 5.1.3 on the server where PunBB is

 2) Explanations

    This vulnerability is grounded on both a mistake in PunBB code
    with an unitialized variable, and PHP Zend_Hash_Del_Key_Or_Index
    vulnerability which allows to bypass the globals deregistration
    process that comes with PunBB. First of all, have a look at the
    unregister_globals() function in "include/functions.php" :

    ************************ BEGIN OF CODE ************************

    function unregister_globals()
        // Prevent script.php?GLOBALS[foo]=bar
        if (isset($_REQUEST['GLOBALS']) || isset($_FILES['GLOBALS']))
            exit('I\'ll have a steak sandwich and... a steak

        // Variables that shouldn't be unset
        $no_unset = array('GLOBALS', '_GET', '_POST', '_COOKIE',
                    '_REQUEST', '_SERVER', '_ENV', '_FILES');

        // Remove elements in $GLOBALS that are present in any of the
        // superglobals
        $input = array_merge($_GET, $_POST, $_COOKIE, $_SERVER,
              $_ENV, $_FILES, isset($_SESSION) &&
              is_array($_SESSION) ? $_SESSION : array());
        foreach ($input as $k => $v)
            if (!in_array($k, $no_unset) && isset($GLOBALS[$k]))

    ************************* END OF CODE ***************************

    Using Zend_Hash_Del_Key_Or_Index vulnerability, it is possible
    to bypass this globals deregistration process. All the details
    on this vulnerability - discovered by Stefan Esser - can be
    found in this article :

    To sum up, as long as PHP meets the required configuration
    for this vulnerability, an attacker is able to set any global
    variable he wants in PunBB. Now, have a look at the file
    "search.php", at the following lines :

    ************************ BEGIN OF CODE ************************

    $row = array();
    while ($temp = $db->fetch_row($result))
         $row[$temp[0]] = 1;

         if (!$word_count)
             $result_list[$temp[0]] = 1;
         else if ($match_type == 'or')
             $result_list[$temp[0]] = 1;
         else if ($match_type == 'not')
             $result_list[$temp[0]] = 0;


    while (list($post_id, $matches) = @each($result_list))
         if ($matches)
             $keyword_results[] = $post_id;


    if ($author && $keywords)
        // If we searched for both keywords and author name we want
        // the intersection between the results
        $search_ids = array_intersect($keyword_results,
        unset($keyword_results, $author_results);
    else if ($keywords)
        $search_ids = $keyword_results;
        $search_ids = $author_results;


    if ($show_as == 'topics')
        $result = $db->query('SELECT FROM '.$db->prefix.'posts
        AS p INNER JOIN '.$db->prefix.'topics AS t ON INNER JOIN '.$db->prefix.'forums AS f ON LEFT JOIN '.$db->prefix.'forum_perms AS fp
        ON ( AND fp.group_id='.$pun_user['g_id'].')
        WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND
        IN('.implode(',',$search_ids).')'.$forum_sql.' GROUP BY', true) or error[...]

        $search_ids = array();
        while ($row = $db->fetch_row($result))
            $search_ids[] = $row[0];


        $num_hits = count($search_ids);

    ************************* END OF CODE *************************

    In this piece of code, the $result_list array is obviously not
    initialized. Using the Zend_Hash_Del_Key_Or_Index vulnerability,
    we are thus able to populate this array with any possible
    content. Consequently, if you perform a search request with only
    a keyword and no author f.e., an attacker is thus able to
    populate $keyword_results and then $search_ids indexes with any
    possible content coming from $result_list. Finally, the
    $search_ids array is imploded and put in the SQL query without
    any protection. In a word, there is an SQL injection here.

 3) Exploitation

    With an adequate UNION query in the $result_list array, an
    attacker is able to perform blind SQL injections and f.e.
    retrieve the entire hash of any user just by looking if the
    script returned some results for his malicious search. For
    example, you can send the following request :

    &result_list[< UNION SQL QUERY >/*]&1763905137=1&1121320991=1

    With such a request, you can disclose each character of the
    admin hash for example. You don't even need to be registered to
    perform this blind SQL injection : all you need is the userid of
    an admin (or any user), and the correct $punbb_db_prefix (very
    often easily guessable if it's not the default one "punbb_").
    Actually, it is possible to go a little bit further and forge
    quite easily an admin cookie. Indeed, the $cookie_seed variable
    which is used to forge more secure cookies, is created during
    the installation in install.php :

    $cookie_seed = substr(md5(time()), -8)

    If you are able to know the past time() of the forum creation,
    you are able to forge an admin cookie using the cookie_seed and
    the admin hash. A very simple way to know this past time() is to
    retrieve the admin value of the "registered" field in the users
    table, seing that the admin account is registered during the
    install, a few lines above the $cookie_seed line in install.php.
    Thus, using the previous SQL injection, an attacker can retrieve
    this "registered" field for the superadmin account and hence
    deduce the time() of the install, then the $cookie_seed value,
    and finally forge an admin cookie.

II] Local File Inclusion / Remote Code Execution Vulnerability

 1) Overview

    PunBB is prone to a local file inclusion in common.php through
    the $pun_user['language'] variable, which can lead to remote
    PHP code execution on servers where PunBB is installed. The
    exploitation of this flaw does not require any special
    configuration of PHP.

 2) Explanations

    PunBB comes with a lot of langage files inclusions in all
    scripts. Among these inclusion, let's focus on the one which is
    systematically performed whatever punbb script is called, in
    include/common.php :

    ************************ BEGIN OF CODE ************************

    @include PUN_ROOT.'lang/'.$pun_user['language'].'/common.php';
    ************************* END OF CODE *************************

    For each user, the $pun_user['language'] variable takes the
    corresponding value of the user 'langage' field in the users
    table. There are only two ways for a user to set or modify this
    value. The first one is in profile.php, but the following
    instruction on line 723 :

    ************************ BEGIN OF CODE ************************
    $form['language'] = preg_replace('#[\.\\\/]#', '',
    ************************* END OF CODE *************************

    prevents to put any malicious content in the langage field. The
    second way is in register.php at the following lines :

    ************************ BEGIN OF CODE ************************

    $language = isset($_POST['language']) ? $_POST['language'] :

    // Add the user
    $db->query('INSERT INTO '.$db->prefix.'users (username,group_id,
    password, email, email_setting, save_pass, timezone,
    language, style, registered, registration_ip, last_visit)
    VALUES(\''.$db->escape($username).'\', '.$intial_group_id.',
    \''.$password_hash.'\', \''.$email1.'\', '.$email_setting.',
    '.$save_pass.', '.$timezone.' , \''.$db->escape($language).'\',
    \''.$pun_config['o_default_style'].'\', '.$now.',
    \''.get_remote_address().'\','.$now.')') or error(...)

    ************************* END OF CODE *************************

    The $langage variable is filled with the value of the user-input
    'langage' without any security check, and is then passed through
    the INSERT query, which allows a newly registered user to put
    any malicious content in his 'langage' field in the users table.
    This obviously leads to a local file inclusion possibility in
    include/common.php .

 3) Exploitation

    In order to get rid of the suffix '/common.php' in the include
    instruction, an attacker can use the classical NULL Byte trick.
    No matter if PunBB addslashes this NULL Byte, because MySQL
    stripslashes it before storing it in the database.

    At this point, it is very classical (and quite simple) to
    execute PHP code using this local inclusion. For example, if
    avatars are enabled, all an attacker has to do is upload a valid
    GIF file with  a malicious PHP content with a previous account,
    then register as a new user and post a 'language' value
    containing the relative path to the malicious image : this way
    he finally gets a shell on the server just by logging in with
    his new account. Besides, he can also, depending on the server
    configuration, disclose the content of server files.
III] Recommandations / Thanks
     The vendor has released a new version which fixes these
     vulnerabilities. It is strongly recommended to upgrade to
     PunBB 1.2.14 which can be found at :
     Special thanks to John and Roman0 for their help in testing
     these vulnerabilities.
Contact : Nms < nms (at) wargan (dot) org >

GPG Key :

Version: GnuPG v1.4.5 (MingW32)

Go to the Top of This SecurityTracker Archive Page

Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2021, LLC