X-Account-Key: account1
X-UIDL: 6218d1545812fd6a581543b5107032c3
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:                                                                                 
Received: from lists.maptools.org (localhost [127.0.0.1])
	by mail.howardsilvan.com (Postfix) with ESMTPS id B7072C420A7
	for <faxguy@howardsilvan.com>; Mon, 16 Nov 2015 05:35:56 -0800 (PST)
Received: from lists.maptools.org ([94.23.4.142] helo=lists.maptools.org)
	by fangorn.howardsilvan.com with SMTP (2.3.3); 16 Nov 2015 05:35:55 -0800
Received: from [10.1.0.241] (localhost.localdomain [127.0.0.1])
	by lists.maptools.org (Postfix) with ESMTP id 18C7B35C030;
	Mon, 16 Nov 2015 08:35:22 -0500 (EST)
Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5])
	by lists.maptools.org (Postfix) with ESMTPS id 8596635C023
	for <tiff@lists.maptools.org>; Mon, 16 Nov 2015 08:35:06 -0500 (EST)
Received: from even-desktop.localnet (unknown [88.162.84.61])
	by smtp5-g21.free.fr (Postfix) with ESMTPS id 9FAE5D4827F;
	Mon, 16 Nov 2015 14:35:02 +0100 (CET)
From: Even Rouault <even.rouault@spatialys.com>
To: tiff@lists.maptools.org
Date: Mon, 16 Nov 2015 14:35:22 +0100
User-Agent: KMail/1.13.5 (Linux/2.6.32-67-generic; KDE/4.4.5; x86_64; ; )
References: <201511141419.20555.even.rouault@spatialys.com>
	<alpine.GSO.2.01.1511140826440.1673@freddy.simplesystems.org>
	<201511141545.10242.even.rouault@spatialys.com>
In-Reply-To: <201511141545.10242.even.rouault@spatialys.com>
MIME-Version: 1.0
Message-Id: <201511161435.22467.even.rouault@spatialys.com>
Subject: Re: [Tiff] ColorMap and high bit depth
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>
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org
X-Assp-ID: fangorn.howardsilvan.com m1-80956-12071
X-Assp-Session: 7F06620EC630 (mail 1)
X-Assp-Detected-RIP: 88.162.84.61, 212.27.42.5
X-Assp-Source-IP: 88.162.84.61
X-Assp-Envelope-From: tiff-bounces@lists.maptools.org
X-Assp-Intended-For: faxguy@howardsilvan.com
X-Assp-Version: 2.3.3(14029) on fangorn.howardsilvan.com
X-Assp-Server-TLS: yes
X-Assp-Delay: not delayed (whitelisted); 16 Nov 2015 05:35:56 -0800
X-Assp-Whitelisted: Yes (whitelistdb)
Return-Path: tiff-bounces@lists.maptools.org
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Le samedi 14 novembre 2015 15:45:10, Even Rouault a =E9crit :
> Le samedi 14 novembre 2015 15:33:42, Bob Friesenhahn a =E9crit :
> > On Sat, 14 Nov 2015, Even Rouault wrote:
> > > Hi,
> > > =

> > > I've noticed that currently we support ColorMap up to BitsPerSample=
=3D28.
> > > Since 3 * 2^28 * sizeof(uint16) =3D 1.6 GB (< 2 GB, which is the sani=
ty
> > > check in TIFFReadDirEntryArray() ). And this is read by default at fi=
le
> > > opening, so it can be used as a sort of DoS due to excessive I/O and
> > > memory usage.
> > > =

> > > Does it make sense to support ColorMap with such high bit depths ?
> > > Couldn't we limit reading ColorTable up to 24 bit for example (which
> > > would put the limit to 50 MB) ? Another option would be to defer
> > > reading the color map until it is explicitly requested by the
> > > application, but do we need such complication ?
> > =

> > 28 bits seems excessive to me.  GraphicsMagick (and likely
> > ImageMagick) only support colormaps with a 16-bit index (it would be
> > nice to support a bit more though).  Colormaps decrease in value as
> > they become larger.
> =

> Agreed
> =

> > The colormap is not compressed so the best defense against DOS is to
> > check that the file has provided the backing data for the colormap
> > before making the memory allocation.  It is easy to declare a 1.6 GB
> > colormap, but much more difficult to supply it.
> =

> The code currently would error out after some time if the file isn't 1.6 =
GB
> large, but 1.6 GB TIFF files are not uncommon at all in my area of intere=
st
> (GIS) for example. But ingesting it in a single gulp for a fake colormap
> isn't really expected :-)

So is there any opposition to me committing the following ?

Index: libtiff/tif_dirread.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvs/maptools/cvsroot/libtiff/libtiff/tif_dirread.c,v
retrieving revision 1.193
diff -r1.193 tif_dirread.c
3756a3757,3767
> 					/* ColorMap or TransferFunction for high bit */
> 					/* depths do not make much sense and could be */
> 					/* used as a denial of service vector */
> 					if (tif->tif_dir.td_bitspersample > 24)
> 					{
> 					    TIFFWarningExt(tif->tif_clientdata,module,
> 						"Ignoring %s because BitsPerSample=3D%d>24",
> 						fip ? fip->field_name : "unknown tagname",
> 						tif->tif_dir.td_bitspersample);
> 					    continue;
> 					}

-- =

Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/


