On October 20, 2002 at 02:34, "Steven M. Christey" wrote:
(I'm assuming this makes it to mhonarc-dev too)
If not subscribed, it will eventually get manually approved by
the list administrator.
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.
This is for Netscape 4, and was previously reported awhile back
by another user related to XSS attacks for text/html messages,
but I believe Netscape 4 only does it for attribute values of
HTML tags. Hence, I do not know off-hand if &{} can be sneaked in
within message headers since the '&' will get converted to '&'.
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.
Agreed.
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.)
From my understanding of .lnk files, they do not function like real
symbolic links. I agree with you that .lnk files could have potential
security problems, but since they do not function like Unix symlinks,
they probably have a different set of problems.
As for IE reading text files as HTML, I know about this extreme
annoyance. The problem also occurs when an HTTP server sends a
text/plain content-type, but IE does a peek at the content, and if
it thinks it looks like HTML, it renders the data as HTML.
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"...
Would utilizing Perl's rand() operator be sufficient?
--ewh
---------------------------------------------------------------------
To sign-off this list, send email to majordomo(_at_)mhonarc(_dot_)org with the
message text UNSUBSCRIBE MHONARC-DEV
