Message-ID: <acdc033d0608151657o5c7a5d88o8a665bbea931444@mail.gmail.com>
Date: Tue, 15 Aug 2006 19:57:14 -0400
From: "Micheal Espinola Jr" <michealespinola@...il.com>
To: Full-Disclosure <full-disclosure@...ts.grok.org.uk>
Subject: ASSP “get?file” Traversal Vulnerability

Anti-Spam SMTP Proxy (ASSP) "get?file" Traversal Vulnerability

Release Date:
August 15, 2006

Notice:
This is a known flaw, and has been since the implementation of an
enhanced web interface for ASSP, since at least 2003. I do not
normally test for security vulnerabilities or address them directly,
but my recently acquired Perl experience prompted me to address this
specific issue.

Severity:
Medium (authenticated user)

Vendor:
Open Source (assp.sourceforge.net)

Systems Affected:
Since at least 2003, all versions of ASSP on any platform running Perl.

Background:
The ASSP server project is an Open Source platform-independent SMTP
proxy server that leverages numerous methodologies and technologies to
both rigidly and adaptively identify spam. ASSP runs as a Perl
application.

Overview:
ASSP uses an URL manipulation to retrieve files it needs for its web
interface. ASSP does not operate as a true web server. ASSP retrieves
its files with the same permissions of the user or the server/daemon
running the Perl application script.

Problem:
Authenticated users, of which there is only one administrative
password configurable for, can manipulate the ASSP address URL in
order to retrieve alternative files locally and across the LAN. While
there is a relative-directory traversal check, there are no other
checks performed. Thus, a malicious user could manipulate the URL to
retrieve a known resource with a local or network UNC path.

This is a particularly troubling security issue when considering
security conscious-less administrators that set the privileges of such
daemons and services (especially Win32) at administrator levels.

Two identical lines in the Perl code provide checks against this
"get?file" functionality. One line is used for the web site interface
itself (for loading images and CSS); the other is for administratively
opening text files for remote-editing purposes. The line of code in
question is:

   if ($fil=~/\.\./) {

As you can see, the only check performed here is if the file path
requested contains ".." .

Exploitable examples:
http://server.domain.tld:55555/get?file=c:\dir\subdir\file.ext
http://server.domain.tld:55555/get?file=\\server\share\dir\file.ext

Protection:
I have come up with a simple replacement for the original line of code
for protection against this vulnerability:

   if ($fil!~/$base\/.*\.(css|gif|jpg|png|txt)$/i) {

This will lock the traversal vulnerability to ASSP's base directory
structure, and will only allow the retrieval of (5) files-types.

Caveat:
I am told that FreeBSD's port of ASSP uses "." as the specified
directory base (reflected in the application as the variable $base),
per the command-line that is used to start ASSP. The base directory is
intended to reflect the actually location of ASSP, and this is an
inappropriate use of the base directory specification. This misuse may
extend to other "ports" of ASSP as well.

If you are using such a port, I recommend the following line of code instead:

   if ($fil!~/.*\.(css|gif|jpg|png|txt)$/i) {

This will not lock the traversal vulnerability to the ASSP directory
structure, but it will at least provide a level of protection for
numerous types of files until a more suitable solution is developed.

Vendor Status:
John Hanna, the creator of ASSP, no longer maintains the code. Other
developers contribute new code and fix bugs "unofficially" off-site.

Fritz Borgstedt, the current principle developer, hosts newly revised
beta code at his website, while the SourceForge web site has stable
code posted to it on occasion.

Related Links:
http://assp.sourceforge.net   (SourceForge home)
http://www.iworld.de/homes/fb/ASSP/   (Fritz's beta development site)
http://www.asspsmtp.org/wiki   (Documentation Wiki)

Copyright (c) 2006 Micheal Espinola Jr:
Permission is hereby granted for the redistribution of this alert
electronically. It is not to be edited in any way without express
consent of Micheal Espinola Jr. If you wish to reprint the whole or
any part of this alert in any other medium excluding electronic
medium, please email michealespinola@...il.com for permission.

Disclaimer:
The information within this paper may change without notice. Use of
this information constitutes acceptance for use in an AS IS condition.
There are no warranties, implied or express, with regard to this
information. In no event shall the author be liable for any direct or
indirect damages whatsoever arising out of or in connection with the
use or spread of this information. Any use of this information is at
the user's own risk.

I hope this is of usefulness to someone – preferably someone that can
address the problem better than I can.

-- 
ME2

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists