My next class:

What's Going on With libtiff?

Published: 2016-06-05. Last Updated: 2016-06-05 17:03:11 UTC
by Johannes Ullrich (Version: 1)
7 comment(s)

"libtiff", as the name implies, is a library used to parse TIFF formatted images. While you don't run into TIFF images on the web every day, the format is quite popular for higher-resolution/high quality applications like printing. TIFF allows the user to select between lossless or lossy compression depending on the preferences of the user.

While the library is very popular, a reader wrote in last week asking if the library is still maintained.

Currently, there are three security issues listed in NIST's vulnerability database. These issues affect the most recent version of libtiff (4.0.6), which was released in September last year.  Popular software, like for example Google Chrome, uses libtiff and could be used to exploit these vulnerabilities.

This issue isn't unique to libtiff. Important libraries (not just open source, the same problem can come up with commercial software as well...) stop being maintained without notice, and users of these libraries have no idea that new vulnerabilities are no longer patched. 

If you develop software, it is critical that you track code that you include (again: open source and commercial). There are a number of check you should perform before adding a library to your repository of "approved third party code":

- is the code still maintained? (e.g. are there any outstanding vulnerabilities known)
- how would you learn about a patch being released? (mailing list? )
- is the code's license compatible with your project? (some open source licenses restrict commercial use)

And most important: Have a repository of "approved third party code"! Don't just include libraries without considering alternatives first. Code reuse is great, and developers should take advantage of already written code, but you have to manage the use of third party code.

And finally: What is your exit strategy? I have no idea what to recommend in the libtiff case. Can you do without it? Can you afford to wait (I don't see any exploits ... yet ... publicly...) 

 

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

Keywords:
7 comment(s)
My next class:

Comments

A couple of points:

"Popular software, like for example Google Chrome, uses libtiff and could be used to exploit these vulnerabilities."

Chrome forks open source projects it uses so it's quite possible that the project patched these issues. However, most projects don't and so could still be exploited - not to mention commercial software that uses it.



"some open source licenses restrict commercial use"

Then they're not really open source.



"And finally: What is your exit strategy? I have no idea what to recommend in the libtiff case."

Fork and move forward. judging by the bug list there are many people who are still actively using the project and I see patches being proposed. The primary maintainer is still alive (he's got projects on github, one of which was updated less than a month ago), but if he's not going to support perhaps someone else will step up.
I'd have to agree with Johannes on this, I've written a boatload of patches for many open source projects, but in many cases the code is no longer maintained (libdnet is an example of this, as there are a few potential issues in this library as well, but there has been no response from the author via email for the better part of 2 years).

If a product cannot be maintained for whatever reason, it should be placed into the public domain (that's just my humble opinion)...
If an open source library you need as a developer is no longer being maintained, then please, if you can find the time, volunteer to maintain it. I realize this is not always possible, either because of time of skill constraints, but if you are developing something you intend to support, and you need such a library, taking over maintenence might be a good idea. This is how the open source community continues to provide better response than many proprietary products -- many people help carry the load.
I don't think libtiff is unmaintained. The issues I think you are referring to are in the tools and not in the library itself. These issues might still be relevant and exploitable, because lots of web applications use command line functions to execute these tools with input from end user (attacker controlled).

Following issues will be handled by removing the tools (thumnail and gif2tiff) from the project.

CVE-2016-3632
CVE-2016-3633
CVE-2016-3634
CVE-2016-5102
A better question should be, why are people using TIFF? PNG is a decent format and everything supports it.
And don't forget to purge unmaintained and vulnerable code from your repository!
[quote=comment#37225]A better question should be, why are people using TIFF? PNG is a decent format and everything supports it.[/quote]
PNG doesn't do layers, or 16-bit per channel, or multiple pages in one file... and various other features that TIFF has. PNG is nice for mainstream use, but there are significant uses where you can't replace TIFF.

Diary Archives