Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: Theo de Raadt (deraadtcvs.openbsd.org)
Date: Mon Jan 21 2002 - 12:15:30 CST
Thanks for your extensive chit-chat without any diffs.
WHat an utter waste of timje.
> Return-Path: eggerttwinsun.com
> Delivery-Date: Sat Jan 12 23:45:52 2002
> Received: from openbsd.cs.colorado.edu (openbsd.cs.colorado.edu [184.108.40.206])
> by cvs.openbsd.org (8.12.1/8.12.1) with ESMTP id g0D6iA3J031014
> (version=TLSv1/SSLv3 cipher=EDH-DSS-DES-CBC3-SHA bits=168 verify=FAIL)
> for <opensshcvs.openbsd.org>; Sat, 12 Jan 2002 23:44:10 -0700 (MST)
> Received: from alcor.twinsun.com (alcor.twinsun.com [220.127.116.11])
> by openbsd.cs.colorado.edu (8.12.1/8.12.1) with ESMTP id g0D6dqRI003988
> (version=TLSv1/SSLv3 cipher=EDH-DSS-DES-CBC3-SHA bits=168 verify=NO)
> for <opensshopenbsd.org>; Sat, 12 Jan 2002 23:39:53 -0700 (MST)
> Received: from sic.twinsun.com ([18.104.22.168]) by alcor.twinsun.com (8.11.3/8.11.3) with ESMTP id g0D6diF20838; Sat, 12 Jan 2002 22:39:44 -0800 (PST)
> Received: (eggertlocalhost) by sic.twinsun.com (8.10.2+Sun/8.10.2) id g0D6dip23266; Sat, 12 Jan 2002 22:39:44 -0800 (PST)
> Date: Sat, 12 Jan 2002 22:39:44 -0800 (PST)
> From: Paul Eggert <eggerttwinsun.com>
> Message-Id: <200201130639.g0D6dip23266sic.twinsun.com>
> To: dugsongmonkey.org
> CC: security-auditferret.lmh.ox.ac.uk, opensshopenbsd.org
> In-reply-to: <20020112150122.GD19026naughty.monkey.org> (dugsongmonkey.org)
> Subject: Re: [open-source] Re: Wish for 2002 ...
> References: <Pine.BSO.4.33.0201111306400.4650-100000etoh.eviladmin.org> <Pine.LNX.4.33.0201111121510.4042-100000penguin.transmeta.com> <20020112004546.A452iv.nn.kiev.ua> <200201120055.g0C0tpl02258shade.twinsun.com> <20020112095207.GC20741faui02> <20020112150122.GD19026naughty.monkey.org>
> > Date: Sat, 12 Jan 2002 10:01:23 -0500
> > From: Dug Song <dugsongmonkey.org>
> > > strlcpy(phost, (char *)krb_get_phost(localhost),
> > > sizeof(phost));
> > that we duplicate the effort in ensuring a NUL-terminated string is
> > just defensive programming against bad Kerberos libraries.
> Before I mentioned that OpenSSH code extract I consulted the source
> code of a library whose krb_get_phost can return a string longer than
> sizeof(phost). (Presumably this is what you mean by "bad".) So
> clearly one cannot simply replace strlcpy with strcpy, as one could
> with the previous OpenSSH code extract analyzed in this thread.
> However, this does not mean that strlcpy is correct here.
> > it wouldn't be any different if we memcpy'd the
> > string in and planted a '\0' in there by hand
> Yes, that wouldn't fix the misbehavior either.
> > > Possibly this misbehavior can lead to a security hole, and possibly
> > > not; I haven't checked.
> > there is no misbehaviour here, only defensive programming
> No, it is defensive programming that leads to misbehavior, because the
> code can end up using a different ticket-granting instance name than
> was requested.
> I don't know whether that misbehavior can be exploited. However, it
> would be safer if the code reported an error instead of silently
> misbehaving when the host name is too long. This would improve the
> quality of the defensive programming.
> This problem suggests that you might want to sweep the code and remove
> all instances of strlcpy/strlcat. Instances such as the above can be
> replaced with strlen + fail-if-too-long + memcpy; that would improve
> code safety. Instances such as the previously-mentioned one can be
> replaced with memcpy; that would be simple, standard, and just as