from SANS Internet Storm Center, InfoCON: green
"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...)
