From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <insight-return-5509-listarch-insight=sources.redhat.com@sourceware.org>
Received: (qmail 23175 invoked by alias); 1 Nov 2005 15:11:45 -0000
Mailing-List: contact insight-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:insight-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/insight/>
List-Post: <mailto:insight@sourceware.org>
List-Help: <mailto:insight-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: insight-owner@sourceware.org
Received: (qmail 23163 invoked by uid 22791); 1 Nov 2005 15:11:42 -0000
Received: from shadbolt.decadentplace.org.uk (HELO shadbolt.decadentplace.org.uk) (88.96.1.122)
    by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 01 Nov 2005 15:11:42 +0000
Received: from [192.168.4.103] (helo=localhost)
	by shadbolt.decadentplace.org.uk with esmtp (Exim 4.50)
	id 1EWxnX-0003Hb-3l; Tue, 01 Nov 2005 15:11:39 +0000
Received: from womble by localhost with local (Exim 4.50)
	id 1EWxnI-0001l2-VA; Tue, 01 Nov 2005 15:11:25 +0000
Subject: RE: Possible security flaw in Insight
From: Ben Hutchings <ben@decadentplace.org.uk>
To: Dave Korn <dave.korn@artimi.com>
Cc: insight@sources.redhat.com
In-Reply-To: <SERRANO1E9GQvnbEG1000000071@SERRANO.CAM.ARTIMI.COM>
References: <SERRANO1E9GQvnbEG1000000071@SERRANO.CAM.ARTIMI.COM>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-HYGfUmsH8zPGvQo14wC1"
Date: Tue, 01 Nov 2005 15:11:00 -0000
Message-Id: <1130857884.1994.24.camel@localhost>
Mime-Version: 1.0
X-SW-Source: 2005-q4/txt/msg00006.txt.bz2


--=-HYGfUmsH8zPGvQo14wC1
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
Content-length: 1422

[I'm not subscribed to the mailing list, so please continue to cc
replies to me.]

Dave Korn wrote:
> Ben Hutchings wrote:
> > This security advisory explains a bug in some versions of Tcl, which
> > may affect Insight.
> >=20
> > Ben.
> >=20
> > readdir_r considered harmful
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
>=20
>=20
>   Well, readdir_r is used in tcl/unix/tclUnixThrd.c as follows:
>=20
> --------------------------------snip--------------------------------
> typedef struct ThreadSpecificData {
>     char	    	nabuf[16];
>     struct tm   	gtbuf;
>     struct tm   	ltbuf;
>     struct {
> 	Tcl_DirEntry ent;
> 	char name[PATH_MAX+1];
>     } rdbuf;
> } ThreadSpecificData;

In some versions of Tcl (8.4.2 to 8.5a2 inclusive), the dimension of the
name field is MAXNAMLEN+1, not PATH_MAX+1.

<snip>
>   I'm with Zaraza (sp?) on this one.  What's wrong with statically sizing=
 it
> to NAME_MAX+1, in accordance with the demands of the posix spec?
<snip>

NAME_MAX isn't required to be defined (and MAXNAMLEN isn't even
mentioned by POSIX, though it is equivalent on many systems).  GNU/Hurd
doesn't define it, for example, because there is no practical limit on
name lengths there.

Ben.

--=20
Ben Hutchings
When you say `I wrote a program that crashed Windows', people just stare ...
and say `Hey, I got those with the system, *for free*'. - Linus Torvalds

--=-HYGfUmsH8zPGvQo14wC1
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
Content-length: 189

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQBDZ4Wc79ZNCRIGYgcRAr8RAJ90LF486Id57D6j847TWdanX9JHQACfdmby
/eYwflqqB3+XAXW1suax0hk=
=a/L8
-----END PGP SIGNATURE-----

--=-HYGfUmsH8zPGvQo14wC1--