What's Going on With libtiff?
"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...)
| Network Monitoring and Threat Detection In-Depth | Singapore | Nov 18th - Nov 23rd 2024 |
Comments
"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.
Anonymous
Jun 5th 2016
8 years ago
If a product cannot be maintained for whatever reason, it should be placed into the public domain (that's just my humble opinion)...
Anonymous
Jun 5th 2016
8 years ago
Anonymous
Jun 6th 2016
8 years ago
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
Anonymous
Jun 6th 2016
8 years ago
Anonymous
Jun 6th 2016
8 years ago
Anonymous
Jun 6th 2016
8 years ago
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.
Anonymous
Jun 6th 2016
8 years ago