[Brent Welch <welch@scriptics.com>] MIME attack on Microsoft and Netscape mail readers

[Brent Welch <welch@scriptics.com>] MIME attack on Microsoft and Netscape mail readers

[Eze Ogwuma]

Hi,

Does anyone have any thoughts on this and its possible interaction
with Gnus and TM?
-- 
Eze Ogwuma
------- Start of forwarded message -------
Resent-Date: 29 Jul 1998 19:02:46 -0000
Resent-Cc: recipient list not shown:;
Message-Id: <199807291901.MAA20280@pop.scriptics.com>
To: exmh-users@redhat.com
Subject: MIME attack on Microsoft and Netscape mail readers
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 29 Jul 1998 12:01:46 -0700
From: Brent Welch <welch@scriptics.com>
Resent-Message-ID: <"4eCFO.0.5K6.K7tlr"@mail2.redhat.com>
Resent-From: exmh-users@redhat.com
Resent-Reply-To: exmh-users@redhat.com
Resent-Sender: exmh-users-request@redhat.com

I've put the following notice on http://www.beedub.com/exmh/

"Recent news articles about security flaws in Microsoft and Netscape mail
readers concern an attack on MIME handling.
Exmh implements MIME handling in Tcl code that is unaffected by
buffer overflow type attacks.  There are no fixed sized buffers
in the implementation of Tcl itself, so it is not possible to
trick Exmh into executing arbitrary code by sending it
MIME attachments with extremely long file names."

--	Brent Welch	<welch@scriptics.com>
	http://www.scriptics.com
	Scriptics: The Tcl Platform Company



-- 
         To unsubscribe: mail exmh-users-request@redhat.com with 
                       "unsubscribe" as the Subject.



------- End of forwarded message -------

Re: [Brent Welch <welch@scriptics.com>] MIME attack on Microsoft and Netscape mail readers

[SL Baur]

Eze Ogwuma <typhoon@dircon.co.uk> writes in ding@gnus.org:

> Hi,
> Does anyone have any thoughts on this and its possible interaction
> with Gnus and TM?

Brent Welch writes:
>> "Recent news articles about security flaws in Microsoft and Netscape mail
>> readers concern an attack on MIME handling.
>> Exmh implements MIME handling in Tcl code that is unaffected by
>> buffer overflow type attacks.  There are no fixed sized buffers
>> in the implementation of Tcl itself, so it is not possible to
>> trick Exmh into executing arbitrary code by sending it
>> MIME attachments with extremely long file names."


XEmacs 20.2 and 19.16 are vulnerable to stack overrun if
`directory-files' is passed an over-long name.  I see one usage of
`directory-files' in tmh-comp.el, but it is used with data typed in by 
a user instead of data extracted from a mail message.  This bug is
fixed in XEmacs 20.3 and 20.4.

Personally, I'm a lot more worried about specially constructed
images displayed in-line.  The XEmacs image code has never been
paranoid enough to satisfy my tastes, though it's better in the
current sources.

Re: [Brent Welch <welch@scriptics.com>] MIME attack on Microsoft and Netscape mail readers

[William M. Perry]

SL Baur <steve@xemacs.org> writes:

> Eze Ogwuma <typhoon@dircon.co.uk> writes in ding@gnus.org:
> 
> > Hi,
> > Does anyone have any thoughts on this and its possible interaction
> > with Gnus and TM?
> 
> Brent Welch writes:
> >> "Recent news articles about security flaws in Microsoft and Netscape mail
> >> readers concern an attack on MIME handling.
> >> Exmh implements MIME handling in Tcl code that is unaffected by
> >> buffer overflow type attacks.  There are no fixed sized buffers
> >> in the implementation of Tcl itself, so it is not possible to
> >> trick Exmh into executing arbitrary code by sending it
> >> MIME attachments with extremely long file names."
> 
> XEmacs 20.2 and 19.16 are vulnerable to stack overrun if
> `directory-files' is passed an over-long name.  I see one usage of
> `directory-files' in tmh-comp.el, but it is used with data typed in by a
> user instead of data extracted from a mail message.  This bug is fixed in
> XEmacs 20.3 and 20.4.
> 
> Personally, I'm a lot more worried about specially constructed images
> displayed in-line.  The XEmacs image code has never been paranoid enough
> to satisfy my tastes, though it's better in the current sources.

  carefully constructed .elc files can crash FSF Emacs (according to
stallman whilst talking about dynamic loading), anybody know if we suffer
from the same problems?

-Bill P.

Re: [Brent Welch <welch@scriptics.com>] MIME attack on Microsoft and Netscape mail readers

[SL Baur]

William M Perry <wmperry@aventail.com> writes in ding@gnus.org:

>   carefully constructed .elc files can crash FSF Emacs (according to
> stallman whilst talking about dynamic loading), anybody know if we suffer
> from the same problems?

Undoubtedly.  (provide 'mule) in a Latin-1 XEmacs without debugging
enabled and start loading Mule .elcs.  I'm sure one of them will cause
a crash.  The bytecode stack is allocated with alloca (putting it on
the hardware stack), that is bounded by an unchecked number taken
directly from the bytecode (maxdepth).  Make that a large enough
number, or a too-small number and you can directly write to the
hardware stack.  I presume this is what Richard is referring to.[1]


I don't know offhand what kind of checks are done with dynamic
loading, but I do know that straight rewriting of the bytecode of a
dynamically loaded .elc that hasn't been fully loaded will cause a
safe error message.

bytecode.c says:

/*
 * define BYTE_CODE_SAFE to enable some minor sanity checking (useful for
 * debugging the byte compiler...)  Somewhat surprisingly, defining this
 * makes Fbyte_code about 8% slower.
 *
 * define BYTE_CODE_METER to enable generation of a byte-op usage histogram.
 */
/* This isn't defined in FSF Emacs and isn't defined in XEmacs v19 */
#ifdef DEBUG_XEMACS
#define BYTE_CODE_SAFE
#endif


(BYTE_CODE_SAFE was defined unconditionally through XEmacs 20.3).

Footnotes: 
[1]  Duh.  I should have looked at the code first:

DEFUN ("byte-code", Fbyte_code, Sbyte_code, 3, 3, 0,
  "Function used internally in byte-compiled code.\n\
The first argument, BYTESTR, is a string of byte code;\n\
the second, VECTOR, a vector of constants;\n\
the third, MAXDEPTH, the maximum stack depth used in this function.\n\
If the third argument is incorrect, Emacs may crash.")