2008.06.22 17:15 "RE: [Tiff] 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