Who do I contact if I find a vulnerability with MHonArc?

You can do one of the following:

Please indicate if it is okay to mention your name in any resulting advisories or patches that may result from your report. If you do not make any indications, all attempts will be made to keep your identity confidential.

Can I obscure email addresses?

See the SPAMMODE resource.

How can I prevent web access to .mhonarc.db files?

MHonArc database files may contain information that you do not want web users to directly access. The best example is when your archive is customized to obscure email addresses. However, in the MHonArc database file, the original, unobscured, addresses exist.

There are multiple solutions to preventing access to database files:

Why are HTML messages a security risk?

HTML can contain dynamic content, like JavaScript. If an HTML message is blindly archived, you are introducing foreign dynamic content to your web site that you have no control over. The best example of this danger is the problem web-based email sites (e.g. Hotmail) encountered when malicious people were sending HTML messages to web-based email users and the messages contained dynamic content that would popup windows (which had a similiar style of the web-based email hosting provider) requesting sensitive information from users (like passwords).

These types of attacks are classified as Cross-Site Scripting (XSS) attacks by the security community. The common goal for XSS attacks is to obtain private information of a user, like browser cookies used for site authentication.

The following is a brief list of some of the security issues related to HTML messages:

MHonArc's HTML filter (documented under the MIMEFILTERS) resource provides functionality of stripping out HTML data to minimize security exploits. Check the document for full details. The general recommendation for the security conscience is to exclude any HTML message data (see next question).

So how can I exclude HTML mail?

The quickest method is via the MIMEEXCS resource:


Unfortunately, for messages that contain only HTML data, the entire message body will be excluded. Therefore, you may still want to show the data, but have it so the HTML markup is completely neutralized. The following resource settings will neutralize the dangers of HTML messages without excluding message data:

<!-- It is common for popular MUA's to provide a text/plain version
     of the text/html version of a message body.  Therefore, we
     use MIMEALTPREFS to choose the text/plain version if available.

<!-- For messages that do not have a text/plain alternative, we
     treat HTML data as text/plain so the content is not lost, but
     HTML markup is escaped and neutralized.
text/html;   m2h_text_plain::filter; mhtxtplain.pl
text/x-html; m2h_text_plain::filter; mhtxtplain.pl

Why doesn't MHonArc, by default, use the specified filename when saving attachments?

A malicious person could send a message with an attachment filename that could overwrite existing content or be interpreted by the web server in some special manner to execute actions. Example: Apache allows for the support for creating .htaccess files to allow configuration settings within a directory. If you have this feature enabled and a message containes an attachment with the specified filename .htaccess and MHonArc blindly used the attachment filename, the attachment will override any existing .htaccess file you created with a version defined by the sender of the message.

Another possibility is that web servers sometimes interpret filenames with certain extensions as executable content, like .shtml, .cgi, .phtml. If MHonArc used the attachment filename, or even just the attachment filename extension, anyone who can send mail that will be archived on your site can introduce executable content.

It is because of the above reasons that the m2h_external::filter documented in the MIMEFILTERS resource advises caution when using the filter options that enable the usage of attachment filenames or filename extensions.

Is it okay to run mhonarc setuid?

NO! It is not okay. First, MHonArc does not pass Perl's taint checks. Second, MHonArc is vulnerable to symlink attacks. Hence, if mhonarc (or any of the utility programs) is setuid, mhonarc can be used for local priviledge escalation attacks.


$Date: 2005/05/25 19:51:01 $
Copyright © 2002, Earl Hood, mhonarc@mhonarc.org