Return-Path: <tiff-bounces@lists.maptools.org>
Delivered-To: info@awaresystems.be
Received: (qmail 10247 invoked from network); 1 Sep 2008 16:25:08 -0000
Received: from kudos.telenet-ops.be ([195.130.136.13])
          (envelope-sender <tiff-bounces@lists.maptools.org>)
          by angelia.telenet-ops.be (qmail-ldap-1.03) with SMTP
          for <info@awaresystems.be>; 1 Sep 2008 16:25:08 -0000
Received: from mindy.telenet-ops.be (mindy.telenet-ops.be [195.130.136.8])
	by kudos.telenet-ops.be (8.13.1/8.13.1) with ESMTP id m81GP7E9018615
	for <info@awaresystems.be>; Mon, 1 Sep 2008 18:25:07 +0200
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mindy.telenet-ops.be (Postfix) with SMTP id CB51D60004
	for <info@awaresystems.be>; Mon,  1 Sep 2008 18:25:07 +0200 (CEST)
Received: from apate.telenet-ops.be (apate.telenet-ops.be [195.130.132.43])
	by mindy.telenet-ops.be (Postfix) with ESMTP id C477860003
	for <info@awaresystems.be>; Mon,  1 Sep 2008 18:25:07 +0200 (CEST)
Received: from duke.maptools.org (r153.dmsolutions.ca [209.217.116.153])
	by apate.telenet-ops.be (Postfix) with ESMTP id 4AAA227EC02
	for <info@awaresystems.be>; Mon,  1 Sep 2008 18:25:07 +0200 (CEST)
Received: from duke.maptools.org (duke.maptools.org [127.0.0.1])
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id m81GNMIj014512;
	Mon, 1 Sep 2008 12:24:15 -0400
Received: from homer.shelbyville.oz
	(ppp121-45-175-46.lns11.adl2.internode.on.net [121.45.175.46])
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id m81GNIxb014509
	for <tiff@lists.maptools.org>; Mon, 1 Sep 2008 12:23:19 -0400
Received: from ron by homer.shelbyville.oz with local (Exim 4.69)
	(envelope-from <ron@debian.org>) id 1KaCBQ-0003bd-1L
	for tiff@lists.maptools.org; Tue, 02 Sep 2008 01:53:16 +0930
Date: Tue, 2 Sep 2008 01:53:16 +0930
From: Ron <ron@debian.org>
To: tiff@lists.maptools.org
Subject: Re: [Tiff] Some security fixes from RHEL
Message-ID: <20080901162316.GC10630@homer.shelbyville.oz>
References: <200808300053.35585.even.rouault@mines-paris.org>
	<48BAB60F.7040207@pobox.com>
	<Pine.SOC.4.64.0808311028060.1110@freddy.simplesystems.org>
	<48BB143F.4020301@howardsilvan.com> <4983.1220245910@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4983.1220245910@sss.pgh.pa.us>
User-Agent: Mutt/1.5.18 (2008-05-17)
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: ron@debian.org
X-SA-Exim-Scanned: No (on homer.shelbyville.oz);
	SAEximRunCond expanded to false
X-BeenThere: tiff@lists.maptools.org
X-Mailman-Version: 2.1.4
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>
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org
X-SpamCatcher-Score: 30 [X]

On Mon, Sep 01, 2008 at 01:11:50AM -0400, Tom Lane wrote:
> Lee Howard <faxguy@howardsilvan.com> writes:
> > Bob Friesenhahn wrote:
> >> If an application needs to be secure/stable in the face of hostile 
> >> files then it should not link against libtiff. 
> 
> > While the above statements are undoubtedly accurate, the sentiments that 
> > they express are unhealthy for the large community that uses libtiff.  
> 
> More than that: they're unhealthy for the future of TIFF itself.
> 
> What this position is basically saying is that "TIFF is unsafe for use
> on the internet".  Well, the internet is a sufficiently large chunk of
> the potential application space these days that making any such
> restriction is effectively signing your own death warrant.

I guess the authors of Internet Explorer didn't get that memo either.

>  People will
> simply stop using TIFF in favor of other alternatives that are more
> widely supported by safer (or perceived-to-be-safer) software.
> 
> As maintainer of Red Hat's libtiff package, I am now seriously wondering
> whether I must recommend that Red Hat disable TIFF support in any
> application that has any internet exposure.

You should recommend they disable all internet access.  It's the only
way to be sure that something terrible, like having your package
repository hacked and security packages trojaned won't happen one day.


> My rough estimate is that the number of packages that would continue
> to support TIFF after such a recommendation would be zero.  libtiff
> would become an instant pariah.

Right.  Like Certificate Authorities became instant pariahs after not
noticing they'd been certifying thousands of identical keys from a very
small set for two full years ...

> I realize that hardening libtiff is likely to be a long and tedious
> process.  But I think failing to accept that you've got to do it is
> a good way to kill the project.

I think failing to understand what that would take and the chances
of actually succeeding against a determined attacker, and assuming
that it's someone else's problem to make something suitable for
_your_ desired use, is an excellent way to ensure the 'hats have
a long and prosperous future.

You've been given some frank and explicit advice, and a patch to
apply for the latest known exploit.  If you choose to ignore the
former and not apply the latter before distributing it to your
users, that would be on your head -- pointing fingers at people
who didn't make the same assumptions you have, but are happy to
share their work with you, doesn't strike me as a terribly
productive chain of thought.

On the bright side though, once you've killed off all the projects
that aren't safe to process untrusted data, you should find you are
left with a distribution so small that it would be quite easy to
maintain single handedly -- so if this is your itch, it's probably
quite doable.  In the same way that libtiff is perfectly functional
for people who don't want to throw random things they found on the
internet through it.  I'm sure if people submit patches for new
bugs they'll get applied eventually if they are correct.  The real
beauty of free software is you can apply them any time you like,
without having to wait for someone else to find the time for that.

It always seems to work much better when people offer to help
rather than insist someone who already gave you so much somehow
owes you more as a result.

Do svidaniya,

 Comrade Hat


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