Return-Path: <tiff-bounces@lists.maptools.org>
X-Original-To: info@awaresystems.be
Delivered-To: info@awaresystems.be
Received: from mx-h.b-one.net (mx-h.one.com [91.198.169.55])
	by mail9.b-one.net (Postfix) with ESMTP id 42778400107
	for <info@awaresystems.be>; Sun, 11 Jul 2010 10:24:37 +0200 (CEST)
Received: by mx-h.b-one.net (Postfix, from userid 106)
	id 26AAB1E24E11; Sun, 11 Jul 2010 10:24:37 +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-h.b-one.net (Postfix) with ESMTP id 731851E24E11 for
 <info@awaresystems.be>; Sun, 11 Jul 2010 10:24:36 +0200 (CEST)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by
 lists.maptools.org (Postfix) with ESMTP id 5F3661D0E5298; Sun, 11 Jul 2010
 03:23:54 -0500 (EST)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com
 [209.85.212.44]) by lists.maptools.org (Postfix) with ESMTP id E67251D0E5293
 for <tiff@lists.maptools.org>; Sun, 11 Jul 2010 03:18:38 -0500 (EST)
Received: by vws14 with SMTP id 14so3162949vws.3 for
 <tiff@lists.maptools.org>; Sun, 11 Jul 2010 01:18:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.129.13 with SMTP id m13mr5975765vcs.132.1278836317979; 
 Sun, 11 Jul 2010 01:18:37 -0700 (PDT)
Received: by 10.220.76.73 with HTTP; Sun, 11 Jul 2010 01:18:37 -0700 (PDT)
In-Reply-To: <alpine.GSO.2.01.1007100820530.12887@freddy.simplesystems.org>
References: <alpine.GSO.2.01.1007081111390.12887@freddy.simplesystems.org>
 <AANLkTinyj84Df6nJ5c8c-Dc4D2GY4B7Ye_cyXkjUYwOy@mail.gmail.com>
 <alpine.GSO.2.01.1007100820530.12887@freddy.simplesystems.org>
Date: Sun, 11 Jul 2010 04:18:37 -0400
Message-ID: <AANLkTilT2zR0ZWGinRq2G4MAQA5FHe-039rrHDaAJ1Ug@mail.gmail.com>
From: Albert Cahalan <acahalan@gmail.com>
To: Bob Friesenhahn <bfriesen@simple.dallas.tx.us>
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

On Sat, Jul 10, 2010 at 9:39 AM, Bob Friesenhahn
<bfriesen@simple.dallas.tx.us> wrote:
> On Sat, 10 Jul 2010, Albert Cahalan wrote:

>> 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.
>
> I tend to agree except for the fact that strlcpy() does absolutely assure
> null termination, even if the programmer made an error.

Uh oh. You have failed to consider the case of a zero-sized buffer.
If your strlcpy overflows with a NUL byte, then it may corrupt a
function pointer. If it doesn't, but you rely on getting a NUL byte,
your app code may leak data by read-overflowing as the 0-byte
"string" gets copied elsewhere.

GraphicsMagick-1.3.12 has two strlcpy implementations that
I could find. Both use assert for this case, which is not what
strlcpy is supposed to do. Also you are either paying the cost
of compiling code with assertions enabled or you are running
without them and being subject to having things possibly
depend on input that an attacker might control.

If compiled without assertions, your strlcpy seems to turn into
strcpy when size is 0. You underflow from 0 to 0xffffffff or
0xffffffffffffffff for the right side of the (length < size-1) comparison.
_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
