Return-Path: <tiff-bounces@lists.maptools.org>
X-Original-To: info@awaresystems.be
Delivered-To: info@awaresystems.be
Received: from mx-j.b-one.net (mx-j.one.com [91.198.169.57])
	by mail9.b-one.net (Postfix) with ESMTP id 02455400107
	for <info@awaresystems.be>; Sat, 10 Jul 2010 15:30:24 +0200 (CEST)
Received: by mx-j.b-one.net (Postfix, from userid 106)
	id EBC84DCE60; Sat, 10 Jul 2010 15:30:23 +0200 (CEST)
X-Virus-Scanned: by one.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=0 tagged_above=0 required=4 tests=[none]
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.4
Received: from lists.maptools.org (lists.maptools.org [65.39.174.144]) by
 mx-j.b-one.net (Postfix) with ESMTP id 3DA33DCE60 for <info@awaresystems.be>;
 Sat, 10 Jul 2010 15:30:23 +0200 (CEST)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by
 lists.maptools.org (Postfix) with ESMTP id B6C521D0E5248; Sat, 10 Jul 2010
 08:29:29 -0500 (EST)
Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com
 [71.74.56.122]) by lists.maptools.org (Postfix) with ESMTP id 25F071D0E411B
 for <tiff@lists.maptools.org>; Sat, 10 Jul 2010 08:27:40 -0500 (EST)
X-Authority-Analysis: v=1.1 cv=eWk9bc5BAcy1KEyGm/gc5mmqTM7Cp/ADlcqpp9MTMWU=
 c=1 sm=0 a=mI6YO6ZdSLUA:10 a=8nJEP1OIZ-IA:10 a=nbTLG9h8ygqXV3TyN3qANg==:17
 a=pGLkceISAAAA:8 a=l4aQWd-FAAAA:8 a=n0vAvVC2AAAA:8 a=lV6oy17-gAR6fGY93lgA:9
 a=3P3LNijurmbYhmR-0kYA:7 a=aUY4dye_KI-wj_dQfNBuMXXiEh4A:4 a=wPNLvfGTeEIA:10
 a=MSl-tDqOz04A:10 a=Sub2Ep5PFSvvyGiO:21 a=bxlUgSpjTvP1sQWy:21
 a=nbTLG9h8ygqXV3TyN3qANg==:117
X-Cloudmark-Score: 0
X-Originating-IP: 66.25.159.162
Received: from [66.25.159.162] ([66.25.159.162:3915] helo=KAM1720) by
 hrndva-oedge04.mail.rr.com (envelope-from <KevinMyers@austin.rr.com>)
 (ecelerity 2.2.2.39 r()) with ESMTP id 0F/75-00342-745783C4; Sat, 10 Jul 2010
 13:27:40 +0000
Message-ID: <55BC4557B69249D8A9494CF5ABCDFD95@KAM1720>
From: "Kevin Myers" <KevinMyers@austin.rr.com>
To: "Albert Cahalan" <acahalan@gmail.com>, "Bob Friesenhahn"
 <bfriesen@simple.dallas.tx.us>
References: <alpine.GSO.2.01.1007081111390.12887@freddy.simplesystems.org>
 <AANLkTinyj84Df6nJ5c8c-Dc4D2GY4B7Ye_cyXkjUYwOy@mail.gmail.com>
Date: Sat, 10 Jul 2010 08:27:31 -0500
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931
Cc: Tiff List <tiff@lists.maptools.org>
Subject: Re: [Tiff] strlcpy vs strncpy
X-BeenThere: tiff@lists.maptools.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TIFF and libtiff discussion <tiff.lists.maptools.org>
List-Unsubscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
 <mailto:tiff-request@lists.maptools.org?subject=unsubscribe>
List-Archive: <http://lists.maptools.org/mailman/private/tiff>
List-Post: <mailto:tiff@lists.maptools.org>
List-Help: <mailto:tiff-request@lists.maptools.org?subject=help>
List-Subscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
 <mailto:tiff-request@lists.maptools.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org

Actually the fact that strncpy zero fills the remainder of the array 
strongly suggests that it *was* intended to be used exactly as many people 
are (mis)using it.  Zero filling the array automatically adds a null 
terminator, except in the case when string length = buffer length.  If you 
did't want to automatically add a null terminator, then why zero fill the 
array???

With regard to strlcpy truncating the string, how can that possibly cause a 
security problem???  I don't see that at all.  Seems like strlcpy is doing 
*exactly* what strcpy should have been doing for all these years to prevent 
buffer overfllows and assure that the string length does not exceed the 
buffer length.  Is truncating the string with no indication that truncation 
has occured a (non-security) flaw?  Perhaps, but not when serving as an 
essentially drop-in replacement for strcpy or strncpy in existing code. 
Having a truncation test would only be useful if you also add additional 
application code to decide what to do in the event that truncation was 
detected, which would definitely make for a non-drop-in replacement.

I tend to agree regarding the use of standard implementations rather than 
rolling your own whenever possible.  However, Bob F. is well versed in 
portability issues because of his support for GraphicsMagick on multiple 
platforms.  If he thinks there are enough compilers in widespread use that 
don't support strlcpy to justify rolling his own, then he may be right.  Bob 
is also a very good programmer, so I suspect that his implementation would 
be quite good, and in any event it would be available for subsequent review, 
verification, and correction/optimization if necessary.  But, couldn't this 
kind of thing (roll-your-own vs. standard implmentation) be handled by 
autoconf or something like that?

My 2 cents worth.

s/KAM


----- Original Message ----- 
From: "Albert Cahalan" <acahalan@gmail.com>
To: "Bob Friesenhahn" <bfriesen@simple.dallas.tx.us>
Cc: "Tiff List" <tiff@lists.maptools.org>
Sent: Saturday, July 10, 2010 06:04
Subject: Re: [Tiff] strlcpy vs strncpy


On Thu, Jul 8, 2010 at 12:25 PM, Bob Friesenhahn
<bfriesen@simple.dallas.tx.us> wrote:

> I see that libtiff is using strncpy() as a safer strcpy() and
> strncat() as a safer strcat(). Unfortunately, strncpy() does include
> a significant design flaw which causes it still to be insecure unless
> additional care is taken. The problem occurs when the string to be
> copied exactly matches the buffer size, in which case the string will
> lack null termination.

That isn't a design flaw. You could argue that strncpy is
a badly chosen name perhaps. The intended use is for
character arrays, such as the one in wtmp and utmp files,
which are not really strings in the normal C sense. Note
how strncpy also zero-fills the remainder of the array; this
behavior only makes sense for the intended purpose.

So strncpy isn't intended to do what you likely want, but strlcpy
really does have a design flaw. It truncates the string. This
can cause a security problem. To deal with that you'd need
to check length and compare... but if you're going to do that
then you've already written as much code as you'd need to
write for doing things the standard and portable way: memcpy.
Yep, that's right, memcpy is in <string.h> for a reason.

> GraphicsMagick is using strlcpy() and strlcat() for secure string
> copies. I will be happy to contribute versions that I wrote myself

Many decent programmers have botched reimplementations
of various str* and mem* functions. You might need two hands
to count the number of tries it took to get strncpy right in the
Linux kernel. Sun shipped a libc that got these functions wrong
when crossing a page boundry. Well-optimized code often has
failures with bytes 0x7f, 0x80, and/or 0xff.

You can expect a modern compiler and C library to cooperate
to provide a regression-tested implementation of str* and mem*
functions that takes full advantage of the hardware. (aware of
cache lines, aliasing issues, special-purpose instructions, etc.)
I strongly suggest using what the platform provides rather than
writing your own.
_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/


_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
