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 [EMAIL PROTECTED] with the
message text UNSUBSCRIBE MHONARC-DEV
