Fresh hole in W3Mail

Type securityvulns
Reporter Securityvulns
Modified 2002-11-13T00:00:00



Nth Dimension Security Advisory (NDSA20021112) Date: 12th November 2002 Author: Tim Brown <> URL: <> / <> Product: W3Mail (up to and including 1.0.6) <> Vendor: CascadeSoft <> 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:

8a9 > use File::Basename; 18c19 < $file = $form->param('file');

> $file = basename($form->param('file')); -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (SunOS)

iD8DBQE90XfrVAlO5exu9x8RAglrAKDUQwUYXt3zZSvusFLHyG9aMvjVnACguxGU QvUUoWkIbgOi9DcW+CUYP/E= =mg/G -----END PGP SIGNATURE-----