[//-------------------------------------------------------------------] [ 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
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 [-------------------------------------------------------------------\\]