AWARE [SYSTEMS]
AWare Systems, , Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
June 2008

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date

Contact

The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems



New Datamatrix section



Valid HTML 4.01!



Thread

2008.06.19 21:34 "Scalability problem in tif_dirread.c - detecting loops in IFD offsets", by Steve Eddins
2008.06.19 22:04 "Re: Scalability problem in tif_dirread.c - detecting loops in IFD offsets", by Frank Warmerdam
2008.06.20 12:02 "Re: Scalability problem in tif_dirread.c - detecting loops in IFD offsets", by Steve Eddins
2008.06.20 13:38 "Re: Scalability problem in tif_dirread.c - detecting loops in IFD offsets", by Bob Friesenhahn
2008.06.20 17:19 "Re: Scalability problem in tif_dirread.c - detecting loops in IFD offsets", by Andrey Kiselev
2008.06.20 18:19 "Re: Scalability problem in tif_dirread.c - detecting loops in IFD offsets", by Edward Lam
2008.06.22 17:15 "Re: Scalability problem in tif_dirread.c - detecting loops in IFD offsets", by Steve Eddins

2008.06.22 17:15 "Re: Scalability problem in tif_dirread.c - detecting loops in IFD offsets", by Steve Eddins

> -----Original Message-----
> From: tiff-bounces@lists.maptools.org
> [mailto:tiff-bounces@lists.maptools.org] On Behalf Of Andrey Kiselev
> Sent: Friday, June 20, 2008 1:19 PM
> To: tiff@lists.maptools.org
> Subject: Re: [Tiff] Scalability problem in tif_dirread.c -
> detecting loops in IFD offsets
>
> On Fri, Jun 20, 2008 at 08:02:32AM -0400, Steve Eddins wrote:
> > Thanks very much for your helpful responses.  Interesting that such
> > files really exist.
>
> You can easily create such a file yourself using you favorite
> binary editor. With that file you can make a DOS attack on
> any TIFF software that is not aware of IFD looping problem.
> These days we should always double check the input data and
> we can trust no one.
>
> Turning to code I should say that I always wanted to rewrite
> it and make a single scan over the file when opening and use
> resulting table later.
> Current TIFFSetDirectory() and TIFFNumberOfDirectories()
> implementations are not efficient for heavily multi-paged
> TIFFs, the IFD offset table can be used here. But be aware of
> in-place TIFF modifications, that table should be properly
> updated too.

Thanks Andrey.

I was aware in general of the problem of malicious image files, and my
question about the necessity of loop detection was really just a momentary
attack of wishful thinking on my part.

I need to do some performance measurements to confirm my guesses about what
our specific problems are.  I should have done that before contacting the
list, I suppose.  Sorry about that.

It might cause us difficulty if libtiff always performed a complete
directory scan upon opening the file.  In our architecture, users may access
images within a TIFF file at different times within a MATLAB session.  These
image reads are done in separate function calls, with no state preserved
between the calls.  We call TIFFclose() after each image read, because
there's no way to hang onto the state, and because it wouldn't be
appropriate for us to keep the file open indefinitely during a session
anyway.  (Anticipated tech support call: "Why can't I delete/move/rename my
file?")
Scanning all the directories on every image read would be a lot of
duplicated effort.

About the TIFFNumberOfDirectories() function - as far as I can tell, this
function is not protected against IFD loops.  It just calls
TIFFAdvanceDirectory() in a while loop, and I don't see any loop-detection
logic in TIFFAdvanceDirectory(). Am I missing something?

Thanks again,

Steve