From xemacs-m  Thu Sep 25 12:41:37 1997
Received: from altair.xemacs.org (steve@xemacs.miranova.com [206.190.83.19])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id MAA20856
	for <xemacs-beta@xemacs.org>; Thu, 25 Sep 1997 12:41:33 -0500 (CDT)
Received: (from steve@localhost)
	by altair.xemacs.org (8.8.7/8.8.7) id KAA00712;
	Thu, 25 Sep 1997 10:47:44 -0700
Mail-Copies-To: never
To: xemacs-beta@xemacs.org
Subject: Re: Fatal serious (security) flaw in XEmacs 19.16/20.3
References: <m2zpp22ae9.fsf@altair.xemacs.org> <86202dwf7a.fsf@kramer.in.aventail.com>
X-Face: (:YAD@JS'&Kz'M}n7eX7gEvPR6U1mJ-kt;asEc2qAv;h{Yw7ckz<7+X_SYeTNAaPui:e~x$
 ,A=gkt*>UPL/}\a/#C~v2%ETiAY_sx;xve0yL??JWTtX_-NUzXyP38UdW#cmN1\4(X!c3m#%IbtB-3
 Z-!xpZi!`E.s{(;aP=b11"!3wQu]1j@^V|;n=B|{l<bZV1.AI`zWV%kPCnUhcgEe\(}/_kNd6,*3ZJ
 Q3o<YQ3^u;7jS=:p0--u3msQO
X-Attribution: sb
From: SL Baur <steve@xemacs.org>
In-Reply-To: wmperry@aventail.com's message of "25 Sep 1997 09:06:33 -0700"
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Date: 25 Sep 1997 10:47:44 -0700
Message-ID: <m2yb4ljnen.fsf@altair.xemacs.org>
Lines: 33
X-Mailer: Quassia Gnus v0.10/XEmacs 20.3(beta24) - "Ljubljana"

William M Perry <wmperry@aventail.com> writes:

>   Yup - definitely a stack overrun.  Not sure why it doesn't cause more bad 
> things to happen (at least on linux I just get a normal error).

There's some slop between the top of statbuf and the stack.  XEmacs
linked against libc5 appears to tolerate the overrun a little more
than XEmacs linked against libc6 (definitely a reason to upgrade in
good time).

>   {
>     /* XEmacs: this should come before the opendir() because it might error. */
>     Lisp_Object name_as_dir = Ffile_name_as_directory (dirname);
>     CHECK_STRING (name_as_dir);
>     memcpy (statbuf, ((char *) XSTRING_DATA (name_as_dir)),
>            XSTRING_LENGTH (name_as_dir));
>     statbuf_tail = statbuf + XSTRING_LENGTH (name_as_dir);
>   }

>   We should actually check XSTRING_LENGTH(name_as_dir) > MAXNAMLEN before
> doing the memcpy.

I took a look at how Emacs handles this function.  They definitely do
it right -- no fixed sized buffers anywhere in the routine.
Unfortunately synching up is non-trivial due to our optional 5th
argument.

>   The real question is why don't we just use Fexpand_file_name and
> make_string instead of mucking directly with the bufers.  Sure it will make
> directory-files slower, but is that ever likely to be in bottleneck code?

I doubt it.  If Emacs can get away with not using fixed sized buffers
in this code, surely we can as well.

