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/
