[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Fresh hole in W3Mail (fwd)

Hash: SHA1


The attached advisory supercedes my previous effort regarding W3Mail
(NDSA20020719).  It seems that in fixing the original holes, CascadeSoft
introduced a new one.

Their fix for the original hole was as I suggested, to move the MIME
attachments data from the web server document root.  Unfortunately, the
script they wrote to allow users to access the attachment, does no
checking about the validity of the file argument, allowing you to request
any file that is readable by the web server user.

The vendor has been notified, but since they never bothered to
acknowledge our contact last time, we're expecting no official response.
Hopefully this time they will be able to correct the bug in less than 4

- -- 
Tim Brown
Version: GnuPG v1.0.7 (SunOS)
Comment: For info see http://quantumlab.net/pine_privacy_guard/

Hash: SHA1

Nth Dimension Security Advisory (NDSA20021112)
Date: 12th November 2002
Author: Tim Brown <mailto:timb@xxxxxxxxxxxxxxxxxxxx>
URL: <http://www.nth-dimension.org.uk/> / <http://www.machine.org.uk/>
Product: W3Mail (up to and including 1.0.6) <http://www.w3mail.org/>
Vendor: CascadeSoft <http://www.cascadesoft.com/>
Risk: Medium
Supersedes: NDSA20020719


This vulnerability comes in 3 related parts.

On 1.0.5 and earlier releases:
1) W3Mail can incorrectly expose downloaded MIME attachments without
correct authentication in cases where the web server has been
configure with indexing for the MIME attachments storage directory.

2) In cases where the web server has server side scripting of any type
(such as PHP) enabled for the MIME attachments directory, it is
possible to gain remote access as the web server user typically nobody.

On 1.0.6:
3) W3Mail can be made to retrieve any file to which the web server user has 
read access (for example /etc/passwd).

Technical Details

On 1.0.5 and earlier releases:
1) Unless indexing for the MIME attachments directory is disabled it
is possible to browse the MIME attachments directory and read
arbitrary attachments.  Prior to release 1.0.3, W3Mail did not
correctly clean up the MIME directory, leaving the attachments there
even after the user whom they belonged to has logged out. In releases
1.0.3 and onwards, providing the user correctly logs out their
attachments will be removed. Note that the attachments will remain as
with 1.0.3 and previous releases if the user simply closes the window
rather than using the correct logout link.

2) By sending a MIME attachment executable by the web server from the
MIME attachments directory to an POP3 account accessed from the W3Mail
web based POP3 client remote access as the webserver user can in
theory be achieved, if the user to whom the mail is sent opens the
malicious email (and thus creates the attachments within the MIME
attachments directory for the lifetime explained in part 1).  Whilst
the attachment exists, the potential intruder can request it via their
browser and therefore have it exected by the web server.  The
attachment must be sent as a none text MIME type in order for the
malicious code to correctly be created. This part of the vulnerability
will work even when directory indexing is turned off for the MIME
attachments directory since attachments are created with their
original name.

This vulnerability can also be exploited on attachments being sent
from W3Mail, although in this case the affect is reduced in releases
from 1.0.3 onwards which clean the attachments directory after the
mail has been sent minimizing the potential time for any attack.

On 1.0.6:
3) In replacing the code to fix the problems described previously, 
CascadeSoft moved the MIME attachments directory out of the document root as 
we initially recommended.  However, the code they introduced to allow access 
to the attachments from the the web page (viewAttachment.cgi) can be made to
read any arbitrary file that the web server user has read access to, as it 
makes no sanity checks on the value passed within the file element of the URL, 
allowing for file=../../../../../etc/passwd etc.  Note that for this to work 
as described the attacker will need a valid session ID.


In order to completely protect against the vulnerability (in the 
short term), Nth Dimension recommend turning off indexing and any server
side file execution for the MIME attachments directory, however it is
our belief that it would be better to rewrite the affected code with a
view to storing attachments (either those being sent or received)
outside the web servers document root.  Release 1.0.6 fixes issues 1 & 2 as 
we suggested but introduces a new hole which allows retrieval of arbitrary 
files using the new readAttachment.cgi script.  It may be mitigated by the
following (untested) patch:

> use File::Basename;
< $file = $form->param('file');
- ---
> $file = basename($form->param('file'));
Version: GnuPG v1.0.7 (SunOS)