(I'm assuming this makes it to mhonarc-dev too)
Earl,
Thank you for acting so quickly on the report and, in addition, taking
the safe route of preserving the anonymity of people who report
vulnerabilities.
I am the source of the vulnerability report, and make myself available
for consultation if desired. As the forwarded report says, I will be
on travel for the next few weeks, but expect to check email several
times a day.
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).
This was probably the case, as most of my modifications were to List-*
headers.
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.
I don't either. There have been reports that a "&{javascript}"
sequence would work on some Netscape versions, but I didn't test that.
2) Symbolic link attack on temporary files
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.
I think that's a fair statement, but symbolic link attacks are often
effective because of poor umasks and the like.
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.
Agreed, the simple ability to modify HTML archives is probably of
greater concern to the typical user, and that is outside the scope of
MHonArc.
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).
I believe that the implicit opinion of people who report security
issues is that user-to-user exploits are a legitimate security
concern. It may be academic in most environments, but there is some
area of concern.
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.
That is unfortunate :-(
Of course, since symlinks are a Unix-thing, than only a Unix-specific
solution is required.
This isn't quite the case, in general. Windows systems have .LNK
files (shortcuts) that have received very little attention by security
researchers, but they are a possibility. That may not be a factor in
this instance, due to .LNK issues being relatively unknown, they are
not well understood (e.g. could someone rename a .LNK file to not use
the extension and still get .LNK behavior? Before you reject this
notion out of hand, stick some HTML into a .TXT file and view it in
Internet Explorer; you get HTML, not text.)
Maybe the best option would be to increase the randomness of the
filename so much that it becomes extremely difficult to predict. This
involves having a filename whose random portion is long enough to
avoid brute force attacks (which is why the process ID can be
ineffective even if it's assigned randomly by the OS). Some
programmers assume that the time-of-day is sufficiently random, but
not if something is run out of "at" or "crontab"...
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?
I'm not knowledgeable in Windows, but I have been told that it is
difficult to perform permissions checks in Windows without actually
performing the intended operation and seeing if it succeeds. It might
be nice to generate warnings to the user if theire permissions are
problematic.
Can someone come up with a real-world example of a symlink attacks
that does not take advantage of stupid permission settings?
With the exception of "setuid" style programs, from what I've seen,
symbolic link attacks depend on stupid permission settings, in
conjunction with low randomness as well as the general lack of secure
options from the programming language itself. Addressing any one of
these factors may be sufficient. Then again, symlink vulnerabilities
are the 5th most common vuln in the last 3 years based on some stats I
will be publicly announcing in a few weeks, and we know how many
stupid users there are :-(
That said, I appreciate the difficulty of addressing such issues in a
multi-platform system. Based on what I've seen, developers who try to
address this issue have multiple options during compilation or
installation that depend on the particular OS; they choose the most
secure option available. However, I've only really seen this in Unix
systems written in C. It seems like increasing the randomness of the
filename may be a good option.
Regards,
Steve Christey
---------------------------------------------------------------------
To sign-off this list, send email to majordomo(_at_)mhonarc(_dot_)org with the
message text UNSUBSCRIBE MHONARC-DEV
