Return-Path: <tiff-bounces@lists.maptools.org>
X-Original-To: info@awaresystems.be
Delivered-To: info@awaresystems.be
Received: from mx-k.b-one.net (mx-k.one.com [91.198.169.58])
	by mail9.b-one.net (Postfix) with ESMTP id 931A0400364
	for <info@awaresystems.be>; Tue,  5 May 2009 14:44:55 +0200 (CEST)
X-Virus-Scanned: by one.com
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=0 tagged_above=0 required=6 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-k.b-one.net (Postfix) with ESMTP id F02BCC21C0E
	for <info@awaresystems.be>; Tue,  5 May 2009 14:44:54 +0200 (CEST)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by lists.maptools.org (Postfix) with ESMTP id BC2BC1D1F3DDB;
	Tue,  5 May 2009 07:41:59 -0500 (EST)
Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30])
	by lists.maptools.org (Postfix) with ESMTP id 6406F1D187DC5
	for <tiff@lists.maptools.org>; Fri,  1 May 2009 01:34:01 -0500 (EST)
Received: by yx-out-2324.google.com with SMTP id 8so1389261yxm.9
	for <tiff@lists.maptools.org>; Thu, 30 Apr 2009 23:34:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.36.198 with SMTP id u6mr2210278ibd.36.1241159641059; Thu, 
	30 Apr 2009 23:34:01 -0700 (PDT)
In-Reply-To: <B108E18B-4822-4A7B-BFC4-BFA68F2384E2@telegraphics.com.au>
References: <op.usz7voo3foqvse@simon.fritz.box>
	<0E2E76C8-CAF8-45B5-BAAD-BDC4939B6CF0@telegraphics.com.au>
	<787b0d920904300041y16f836bx87caec73e17e9ebf@mail.gmail.com>
	<869A614C-C44E-4F4F-821D-B1934573CAD2@telegraphics.com.au>
	<787b0d920904301212l5ef55bf8q90ae726b091f07df@mail.gmail.com>
	<DE7A57F5-D99E-4B61-8ABD-55B611D24277@telegraphics.com.au>
	<787b0d920904301231m5b5998ecr994847b922badf0f@mail.gmail.com>
	<B108E18B-4822-4A7B-BFC4-BFA68F2384E2@telegraphics.com.au>
Date: Fri, 1 May 2009 02:34:01 -0400
Message-ID: <787b0d920904302334s33c4d02aw1de835acd5795293@mail.gmail.com>
From: Albert Cahalan <acahalan@gmail.com>
To: Toby Thain <toby@telegraphics.com.au>
Cc: TIFF list <tiff@lists.maptools.org>
Subject: Re: [Tiff] Packbits worst case encoded length
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 Thu, Apr 30, 2009 at 6:30 PM, Toby Thain <toby@telegraphics.com.au> wrote:
> On 30-Apr-09, at 3:31 PM, Albert Cahalan wrote:

>> The alternative is that every app is structured
>> like Google Chrome. It's a really sad result.
>
> I'm not sure what you mean here. I have avoided Chrome so far.

Google Chrome developers pretty much assume that all
libraries have security holes. They run the libraries in
separate low-privilege processes.

(yet still, the protection isn't perfect)

Much the same has been discussed for GNOME and Firefox.
Image rendering libraries run in separate processes, fenced
in by SE Linux policy.

> My objection (in so far that 'my' anything is relevant to this list, which
> isn't much) is not that I'm a super-programmer whose code is always
> bug-free. It is that such mechanism may not belong in a library like
> libtiff.

Suppose the library did this:

void (*guarded_malloc)(size_t); // *.h file

void (*guarded_malloc)(size_t) = malloc; // *.c file

buffer = guarded_malloc(nbytes); // usage

Library users could then do:

guarded_malloc = my_guarded_malloc_function;

You'd also need to cover any functions that need to
be compatible: free, realloc, calloc, and strdup.

> IIRC, OpenBSD has a memory allocator which fences with unmapped guard
> pages[1,2]. ALL applications & libraries benefit. But this won't catch *all*
> buffer overflows, or even any dangerous ones, necessarily. It could be a
> useful debugging tool, though[3].

IIRC, that's only for the large chunks of memory that malloc
gets from the kernel. If you ask for a pair of half-page allocations
you may get them adjacent to each other. You'll get guard pages
around the **pair** of half-page allocations.

> In any case, I write as many bugs as anyone else. My approach to finding
> bugs in a file format parser is to test. And test more. Fuzz testing with
> random input I find is revealing. Memory protection hacks, while a nice
> extra safety net, and definitely valuable in an operating system, are not a
> substitute for that.

That's an excellent idea, but you might not catch everything.
_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
