| [TOC][Manual][Home] |
|
Who do I contact if I find a vulnerability with MHonArc? |
You can do one of the following:
You can submit a report at <https://savannah.nongnu.org/bugs/?func=addbug&group=mhonarc>. Make sure to fill out all required information, and for the Bug Group form item, select Security.
Note: All reports submitted for MHonArc via savannah are automatically mailed to the mhonarc-dev@mhonarc.org list, which is archived at <http://www.mhonarc.org/archive/html/>.
Or, you can send a mail message to mhonarc@mhonarc.org. This address goes directly to the author(s) of MHonArc, and is not archived on any public site.
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:
In v2.6, and later, the DBFILEPERMS resource exists to control the file permissions of the database file. By default, the resource is set to a value that denies world read access. If the archive files are owned by a different user ID than the web server process (which is normally the case), then access to database files will be denied.
| NOTE: | DBFILEPERMS is applicable to Unix-based systems. Therefore, if using a different operating system, you may have to use one of the other solutions to deny access. |
Generate the archive in a non-web accessible location, and then mirror files into a web-accesible locations, excluding the database file. The drawback to this approach is it adds extra administrative and processing overhead.
Generally, web servers provide the ability deny access to files. Refer to your web server's documentation for the specifies. If you are using the Apache HTTP server, the following configuration directive can be used:
<Files .mhonarc.db>
Order allow,deny
Deny from all
</Files>
If you have mod_rewrite enabled, you could use the following instead:
RewriteRule ^(.*)/.mhonarc.db $1 [R=permanent]
This will redirect browsers to the parent directory, which is the actual archive associated with database file.
The DBFILE resource can be used to rename the database file to some arbitrary, not easily guessed, name of your choosing. However, this does not prevent brute force attempts to access the file.
DBFILE resource can be set to a full pathname that is in a non-web server accessible location.
| NOTE: | Using a full pathname for DBFILE is supported only in v2.5.13, or later. |
|
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:
<MIMEExcs> text/html text/x-html </MIMEExcs>
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.
-->
<MimeAltPrefs>
text/plain
text/html
</MimeAltPrefs>
<!-- 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.
-->
<MIMEFilters>
text/html; m2h_text_plain::filter; mhtxtplain.pl
text/x-html; m2h_text_plain::filter; mhtxtplain.pl
</MIMEFilters>
|
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.
| [TOC][Manual][Home] |
MHonArc