Re: tiff / tiff3 / CVE-2015-7554 / CVE-2016-5318

[Brian May <bam@debian.org>]

Raphael Hertzog <hertzog@debian.org> writes:

> 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.

You are probably right.

However I am still a bit confused with this. According to
http://bugzilla.maptools.org/show_bug.cgi?id=2564:

"However, `field_passcount' is always assigned TRUE if the tag is
processed by `_TIFFCreateAnonField()'.  This happens on unsuccessful
invocations of `TIFFReadDirectoryFindFieldInfo()'"

Oh, wait, only happens on *unsuccessful* invocations of
`TIFFReadDirectoryFindFieldInfo()' - oops - missed that detail.

What does the TIFFReadDirectoryFindFieldInfo function do? What
situations is TIFFReadDirectoryFindFieldInfo unsuccessful?

> 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)

Definitely. Having a C function take a variable number of arguments that
can vary depending on runtime state sounds like a recipe for disaster to
me.

You could perhaps mitigate by requiring an extra parameter that declares
the number of options you are parsing, however I think the chances of
getting it wrong are high.
-- 
Brian May <bam@debian.org>