* [Brent Welch <welch@scriptics.com>] MIME attack on Microsoft and Netscape mail readers @ 1998-07-29 22:57 Eze Ogwuma 1998-07-30 0:35 ` SL Baur 0 siblings, 1 reply; 4+ messages in thread From: Eze Ogwuma @ 1998-07-29 22:57 UTC (permalink / raw) 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 ------- ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Brent Welch <welch@scriptics.com>] MIME attack on Microsoft and Netscape mail readers 1998-07-29 22:57 [Brent Welch <welch@scriptics.com>] MIME attack on Microsoft and Netscape mail readers Eze Ogwuma @ 1998-07-30 0:35 ` SL Baur 1998-07-30 0:43 ` William M. Perry 0 siblings, 1 reply; 4+ messages in thread From: SL Baur @ 1998-07-30 0:35 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Brent Welch <welch@scriptics.com>] MIME attack on Microsoft and Netscape mail readers 1998-07-30 0:35 ` SL Baur @ 1998-07-30 0:43 ` William M. Perry 1998-07-31 6:25 ` SL Baur 0 siblings, 1 reply; 4+ messages in thread From: William M. Perry @ 1998-07-30 0:43 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Brent Welch <welch@scriptics.com>] MIME attack on Microsoft and Netscape mail readers 1998-07-30 0:43 ` William M. Perry @ 1998-07-31 6:25 ` SL Baur 0 siblings, 0 replies; 4+ messages in thread From: SL Baur @ 1998-07-31 6:25 UTC (permalink / raw) 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.") ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~1998-07-31 6:25 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1998-07-29 22:57 [Brent Welch <welch@scriptics.com>] MIME attack on Microsoft and Netscape mail readers Eze Ogwuma 1998-07-30 0:35 ` SL Baur 1998-07-30 0:43 ` William M. Perry 1998-07-31 6:25 ` SL Baur
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).