(I'm directing my message to mhonarc-dev list since these are issues
relevent to the list. The original sender has been bcc'ed. I'll be
happy to work as a middle-man to the list if the original sender does
not want to post directly to mhonarc-dev)
On October 19, 2002 at 19:35, someone wrote:
Version tested: MHonArc 2.5.12
Package available in Debian distribution?
1) Cross-site scripting (XSS) possibilities
- XSS can be inserted into the message MIME header names, e.g.:
To: <someone(_at_)example(_dot_)com>
From: <hacker(_at_)example(_dot_)com>
Header<SCRIPT>hello</SCRIPT>def: whatever
Fix: apply the "HTML quoting" capability to all header names and
values.
User workaround: remove the "-extra-" option from the "FieldOrder"
resource, which says which headers should be archived.
Yep. I have just commited a change to mhutil.pl into CVS that
should fix this problem.
- There was partial success in MIME header *values* (not the
standard to/From) where a "<SCRIPT" could be returned partially
unquoted; but I couldn't figure out a way to get the closing ">"
to be added. Most unfortunately, I accidentally removed the test
message, and the malicious string was weird enough that I can't
quite remember what it was, probably a "<<SCRIPT>whatever
here</SCRIPT>" value (i.e. a double "<<"). This (or something
similar) can at least result in a link like this:
<a href="mailto:<SCRIPT>whatever here</SCRIPT>"><SCRIPT</a>
Notice how the last "<SCRIPT" is unquoted. IE seems to ignore
this and use the "</a> to close the tag, but who knows all the
creative things that browsers will do when dealing with
non-perfect HTML! :)
It could have been related to a List-* header since MHonArc attempts
to create links for the field values (List- headers are described in
RFC 2369). The changes to mhutil.pl also contained a change to
how the links are created. It now links only items in <>'s that
start with the following regex:
<\w+:
I think the requirement of the ':' should prevent scripting markup.
Before that, I think you would get what you are describing, but I
do not know if a real vulnerability existed.
2) Symbolic link attack on temporary files
MHonArc uses predictable file names (based on process ID) for the
archive database, .mhonarc.db. If an attacker has write access to
the directory where the database is stored, then the attacker can
use a symbolic link attack to corrupt arbitrary files as the user
running MHonArc. The attacker would have little control over the
contents of the file.
I'm not sure about this one. Symbolic link attacks are definitely
an issue with root processes. When non-root, I unsure of the severity
since normal directory and file permissions would be effective.
If a person makes a directory to be writable by others, then symlinks
attacks are just one of many problems opened up if the "others" are
un-trusted.
I guess the issue is if MHonArc should be written to be safe if executed
under root. IMHO, a person is not a good admin if mhonarc is executed
as root, and I do not know of any user that does this. But, it is a
concern that should be addressed and documented depending on what
gets decided.
Note, I have thought about the symlink attack for mhonarc, but I
cannot see a real vulnerability unless mhonarc is executed as root
(or more importantly, suid, but mhonarc is known to not past Perl's
taint checks).
Fix: use more secure ways of opening temporary files, possibly the
sysopen() call; see the Bugtraq post:
http://security-archive.merton.ox.ac.uk/bugtraq-200002/0104.html
However, if portability is an issue, then creating a temporary
directory with a user-only read/write umask, and creating the
temporary file in there, might be sufficient.
This suggestion is still non-portable. Have you ever wondered why
MHonArc's basic archive locking method is to use a directory file?
Of course, since symlinks are a Unix-thing, than only a Unix-specific
solution is required. On a non-Unix system, thinks like umask have
now meaning.
Wouldn't it be easier to just check the permissions of the archive
directory and report a warning if the directory is writable by others?
Unsure if such checks are portable, but it could be done at least for
Unix-based systems.
Vulnerable code: see "$tmpfile" in lib/mhdb.pl, which uses the
process ID
- Check general symlink issues on all file opens. Is there good
symlink prevention for Perl code? MHonarc seems cross-platform,
which could make it an issue.
Workaround: modify the output database filename command line option
to point to a directory where only the MHonArc user has write
access.
I'm still wondering if this concern is overkill since the archive
directory should already have the proper permissions set. I.e. If
the archive directory allows writing by other uids, than symlink attack
is the least of your worries. So what if the database file is safe.
If the actual HTML files are not, you still have not gained anything.
3) MHonArc's spam address protection can be defeated when the
addresses are stored unmodified in the .mhonarc.db database file,
and the file is stored in the same directory as the HTML output.
This is the default behavior.
NOTE: this configuration issue is already described in MHonArc's
"Security FAQ." It is included here for completeness to remind
admins to verify their own configuration.
Workaround: modify output database filename to be something other
than .mhonarc.db; also modify to be placed outside web-accessible
directories.
Issue already covered:
http://www.oac.uci.edu/indiv/ehood/MHonArc/doc/faq/security.html
The DBFILE resource exists to change the name of the database file.
However, its value is always treated as relative to OUTDIR. It
is reasonable where if DBFILE looks like an absolute pathname,
it will treat it as such. This would allow users to locate the
database file in a separate location from the archive.
I've checked in changes into CVS that supports an absolute pathname
for DBFILE. Note, DBFILE resource can only be set via envariable
or the command-line. This is definitely useful for placing a
dbfile outside of the web accessible area to further decrease any
probabilities that the file could be web accessed.
4) Can we poison the mail archive directory using mh messages with
non-numeric names? May be opportunity for diretory traversal, etc.
Consider e.g. file_open(), file_create, or file_copy in
lib/mhfile.pl - may also be subject to symlinks.
mhamain.pl line 316 - uses file_open() on files in an MH directory.
The default "MHPATTERN" regexp limits this to numeric filenames
like "1", "172", etc. But if an attacker can modify the mbox
directory, they could place a symlink with a numerical name into
the directory, and have the symlink point to other files that are
only readable by the MHonArc user; as a result, these private files
could wind up being published on the web within the mail archive.
file_create() is subject to symlinks, and is used in mhamain.pl
(line 1038, temporary file) and elsewhere.
I still believe that if write permissions exists for others, than
symlinks are the least of your worries. In the scenario you provide
above, if they have write access to the MH directory, they could
just put malicious numeric files directly in there. However,
the symlink exploit does allow one to bypass permissions of files
outside of the MH directory.
5) admin/mhaadmin.cgi needs a good look - but note that it was listed
as experimental.
Yep. It probably have plenty of security problems. I wrote it
years ago to learn Javascript. Maybe I should remove it since I
have no real motivation to try to fix it or maintain it.
Other types of issues were examined but not found.
1) directory traversal issues? e.g. via an attachment filename,
content type, etc.?
The attachment filename gets normalized to "XXXXXX.ext" where X is
a number
(but can we play around with the extension itself? Apparently
not.)
Any leading pathname components in a specified filename are stripped.
Plus, by default, the filename is ignored and a filename is generated
by the content-type according to the table defined in mhmimetypes.pl.
Security warnings are provided in the docs if filename usage is
enabled (see MIMEFILTERS and the m2h_external::filter).
For now, the issue to make a decision for is the symlink problem.
Since mhonarc cannot run suid (Perl's taint checks prevents it),
is root executing mhonarc directly a problem. One could make the
argument that if the data the root owned mhonarc process is reading
is writable by others and that the archive directory is writable by
others, the user gets what's coming to him.
Can someone come up with a real-world example of a symlink attacks
that does not take advantage of stupid permission settings? Is this
an issue that is sever enough that it requires an immediate attention?
--ewh
P.S. Thanks to the person who raised these important issues.
---------------------------------------------------------------------
To sign-off this list, send email to majordomo(_at_)mhonarc(_dot_)org with the
message text UNSUBSCRIBE MHONARC-DEV
