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