Re: tiff / tiff3 / CVE-2015-7554 / CVE-2016-5318
Hi,
On Wed, 14 Sep 2016, Brian May wrote:
> CVE-2015-7554 / http://bugzilla.maptools.org/show_bug.cgi?id=2564
>
> Duplicate:
>
> CVE-2016-5318 / http://bugzilla.maptools.org/show_bug.cgi?id=2561
>
> What would be considered an acceptable fix here? It looks like a proper
> fix is not available without changing the API due to limitations in the
> stdarg.h API. Plus IMHO the TIFFGetField API looks badly designed and
> prone to error considering these known limitations.
(I spent a lot of time on tiff3 issues yesterday.)
I agree on all this but somehow I have the feeling that we can still
do better for example by blacklisting tags that are known to use a single
extension and refusing to handle them as custom
My problem is that I'm not sure that we have a comprehensive list of such
tags. In particular not one that is available in some structure. In other
words, we would have to build up that list and hardcode it into the code.
We could build that list from all the tags which are used in CopyField
(as opposed to CopyField2 or CopyField3) in the various tools. That would
be a good start IMO.
In any case, this is really a hack to mitigate the issue that should be
fixed with a better API IMO. (Feel free to share my comments with
upstream)
> There is a fix for the tiffsplit client program:
>
> http://bugzilla.maptools.org/show_bug.cgi?id=2564#c2
>
> Is it worth trying to fix tiffsplit (like Redhat), and maybe somehow
> documenting somewhere (e.g. the DSA/DLA) that the scope of the fix is
> restricted?
To me it looks like the RedHat patch fixes the issue with the specificly
crafted file... but you can just recreate the same problem with
another (non-standard) tiff tag and their patch is then useless.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/
Reply to: