phpBB Attachment Mod Directory Traversal HTTP POST Injection

From: Paul Laudanski (zx_at_castlecops.com)
Date: 12/14/04

  • Next message: Giovanni Delvecchio: "[ZH2004-18SA] Content-Type spoofing in Mozilla Firefox and Opera could allow users to bypass security restrictions" 
    Date: Tue, 14 Dec 2004 04:58:53 -0500 (EST)
To: bugs@securitytracker.com, <bugtraq@securityfocus.com>, <full-disclosure@lists.netsys.com>, <moderators@osvdb.org>, <news@securiteam.com>, <vuln@secunia.com>, <vulnwatch@vulnwatch.org>

    [//-------------------------------------------------------------------]
    [ CastleCops(SM) Security Advisory 14 Dec 2004 ]
    [---------------------------------------------------------------------]
    [ http://castlecops.com/ ]
    [---------------------------------------------------------------------]

    Severity: High
       Title: phpBB Attachment Mod Directory Traversal HTTP POST Injection
        Date: 7 December 2004
          ID: http://castlecops.com/postp393483.html

    [---------------------------------------------------------------------]

    Summary
    -------
    phpBB is "a high powered, fully scalable, and highly customizable
    open-source bulletin board package. phpBB has a user-friendly
    interface, simple and straightforward administration panel, and
    helpful FAQ. Based on the powerful PHP server language and your
    choice of MySQL, MS-SQL, PostgreSQL or Access/ODBC database servers,
    phpBB is the ideal free community solution for all web sites."

    An HTTP POST Injection exists in the Attachment Mod written by Meik
    Sievertsen AKA Acyd Burn (acyd.burn@gmx.de / http://opentools.de)
    that enables anyone to traverse directories on the web server.

    Affected Packages
    -----------------
    - Attachment module 2.3.10 and earlier

    Immune Packages
    ---------------
    - Attachment module 2.3.11

    Description
    -----------
    Due to the lack of properly sanitizing the filename in the
    attachment mod user interface, a user may inject a filename via
    HTTP POST that includes directory traversal: "../../". This filename
    injection is inserted (or updated) into the attachmod table
    ($prefix_attachments_desc) in the "physical_filename" and/or
    "real_filename" fields. The attach_mod/posting_attachments.php file
    requires filename sanitization to prevent the directory traversal
    portion from being saved in the table.

    Once the database table has a directory traversal filename stored
    such as "../../$newfilename", using the download.php file to obtain
    the download will traverse outside the UPLOAD_DIR location and send
    the "../../$newfilename" to the user (where $newfilename is the name
    of an actual file on the filesystem). This has been tested in the
    website's webroot only, and not outside of it. However, in theory,
    a server could serve up files in /etc or elsewhere via this method.

    In addition, theory suggests that
    attach_mod/includes/functions_attach.php's unlink_attach function
    may not properly sanitize the $filename when a user tries to delete
    a file. It is suggested the author inspect this and patch as
    required.

    Impact
    ------
    With this an attacker could be able to add/remove/execute files
    outside of the UPLOAD_DIR directory.

    Proof Of Concept
    ----------------
    1) Visit a website that has attachmod installed in phpBB.
    2) Start a new topic, attach a file via the "Add Attachment" input
       button.
    3) Prior to clicking "Submit", view the page source via your
       browser's "View Source".
    4) Modify the <FORM> entry if required to send the POST back to the
       website.
    5) Modify the two values for the input names "attachment_list[]" and
       "filename_list[]" from "$oldfilename" to "../../$newfilename".
    6) Save the page, load it in your browser, and click "Submit".

    An unpatched attachmod site will now have "../../$newfilename" in:

    $prefix_attachments_desc.physical_filename
    $prefix_attachments_desc.real_filename

    And when a user accesses the file via the attachmod download.php
    generated link, instead of serving "$filename" from the UPLOAD_DIR
    location, it shall serve to the user the "../../$newfilename" if
    it exists.

    Solution
    --------
    A test patch has been applied and tested successfully. Such a patch
    may include the use of simply replacing both the ".." and "/" with
    an empty string. functions_attach.php only replaces "/" with "\\"
    that is not sufficient.

    Optimally, a patch to this exploit should not allow "../../" to be
    saved to the database at all.

    The approved patch method is to upgrade to Attachment module 2.3.11.
    This patch uses PHP's basename (http://php.net/basename) to
    sanitize the filename, a simple and elegant solution:
    http://opentools.de/board/viewtopic.php?t=3590.

    An alternative patch might consist of the SanitizePath function that
    my wife, Robin Laudanski (AKA IACOJ), brought to the attention of
    the PHP-Nuke community over a year ago at
    http://nukecops.com/article910.html.

    Vendor Status: FIXED
    -------------
    Dec 7 2004: Exploit discovered during an audit.
    Dec 8 2004: Author was contacted with this advisory.
    Dec 9 2004: Author developed a patch. Basic static test of the
                 patch shows success in stopping the exploit.
    Dec 12 2004: Author released version 2.3.11 to the public.
    Dec 14 2004: Advisory released to the public.

    No Warranty
    -----------
    ALL SUCH INFORMATION, SOFTWARE, PRODUCTS, AND SERVICES ARE PROVIDED
    "AS IS" WITHOUT WARRANTY OF ANY KIND. CASTLECOPS, ITS AFFILIATES,
    AND/OR THEIR RESPECTIVE SUPPLIERS HEREBY DISCLAIM ALL WARRANTIES
    AND CONDITIONS WITH REGARD TO THIS INFORMATION, SOFTWARE, PRODUCTS,
    AND SERVICES, INCLUDING ALL IMPLIED WARRANTIES AND CONDITIONS OF
    MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE, AND
    NONINFRINGEMENT.

    Comments
    --------
    Because security is everything, CastleCops encourages the pursuit
    of education and health in security, privacy, and computing via
    the continuous renewal of open discussions for the benefit of all.
    Your feedback is appreciated: http://castlecops.com/forums.html.

    Credits
    -------
    Provided by Paul Laudanski (AKA Zhen-Xjell) from CastleCops,
    http://castlecops.com.

    License
    -------
    Copyright 2004 CastleCops(SM)
    http://castlecops.com/article1.html

    [-------------------------------------------------------------------\\]

  • Next message: Giovanni Delvecchio: "[ZH2004-18SA] Content-Type spoofing in Mozilla Firefox and Opera could allow users to bypass security restrictions"