Re: DRAFT: eXIf 2017-03-09

Mainly what it achieves is to remind encoders that are
converting a TIFF with widely-separated IFDs that they
either have to fill in the gap with whatever they like,
or, more sensibly, remove the gaps and adjust the
pointers to the IFDs accordingly.  For people copying
a JPEG APP1, not so much, because that has probably
already been taken care of.

Glenn


On Sat, Mar 11, 2017 at 10:03 PM, John Bowler
<[email protected]> wrote:
> EXIF/ITFF and ICC seem to have this problem in common; they both
> contain a table (ICC) or tables (TIFF) which contain offsets to data
> outside the tables.  It is pretty easy to deliberately produce valid
> ICC profiles which contain bytes that are not referenced by any entry
> in the table and, so far as I can see, the same applies to EXIF.
>
> However this seems to me to be a trivial security issue.  For sure an
> encoder might leave a gap, but for it to be a security issue the
> encoder has to leave the gap filled within interesting data.  Yes, I
> know this happens, but this is two bad bugs; what does warning encoder
> writers that they could write a valid EXIF chunk with uninitialized
> data actually achieve?
>
> John Bowler

------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford