2016.06.05 14:25 "Re: [Tiff] TiffLib tools as a means for mitigating the ImageTragick exploit", by Bob Friesenhahn

Clearing up some misconceptions around the "ImageTragick" bug https://lcamtuf.blogspot.jp/2016/05/clearing-up-some-misconceptions-around.html

  If all you need to do is simple transcoding or thumbnailing of potentially
  untrusted images, don't use ImageMagick. Make a direct use of libpng,
  libjpeg-turbo, and giflib; for a robust way to use these libraries,
  have a look at the source code of Chromium or Firefox. The resulting
  implementation will be considerably faster, too.

Many people (even very competent programmers) may find it challenging to write an application interface to these libraries which satisfies requirements and is also secure.

One question I'd like to ask: how about the accessory programs which come with TiffLib? Using bmp2tiff, gif2tiff, tiff2pdf, etc. instead of ImageMagick is in accord with the above advice, but how can one tell that this is really an improvement security-wise?

While some of the libtiff utilities can be considered reasonably secure, a number of them have known issues or are essentially worthless as is (e.g. gif2tiff is essentially worthless). The many outstanding CVEs in the libtiff utilities are harming the reputation of libtiff itself:

https://bugzilla.redhat.com/buglist.cgi?quicksearch=libtiff http://bugzilla.maptools.org/buglist.cgi?product=libtiff

I'd like to re-phrase my question in general terms. One looking for alternatives to ImageMagick for a certain task may encounter an image processing tool which provides the necessary functions but whose name is not well known. Lack of publicity may well be an indication of absence of active maintenance. Where does one draw the line?

USENIX Login Volume 41, No. 2, has an article "Fuzzing Code with AFL" by Peter Gutmann which cites some interesting studies which reveal that most software has problems given unexpected inputs. Unless software has undergone many rounds of fuzz-testing and fixing it is highly likely to have issues.

Lack of active maintenance might not be important if the software was written securely in the first place. Note that libjpeg 6b was unmaintained for a great many years but few security issues were found with it while it was in active use. Actively maintained code might not be actively fixed. Distrust software which has not been fuzz-tested and/or which does not admit problems or document fixes which were made.

GraphicsMagick (derived from ImageMagick in late 2002) has undergone considerable fuzz testing for the past 1-1/2 years. Fixes were first delivered in the 1.3.21 release. Many more fixes were delivered in subsequent releases. Almost all known issues (except for one file) were fixed by the most recent 1.3.23 release, although additional fuzzing is likely to find previously unknown issues. Perhaps 95% of the issues discovered by fuzzers were in old code inherited from ImageMagick. Much of it was written in the early to mid '90s.

As far as libtiff and its utilities goes, a large number of problematic files have been submitted and much work remains to be done. Most problems appear to be in utilities code.

It is wise to deprecate/jettison libtiff utilities which are so out of date that they serve no useful purpose.

Bob
--
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/