Brian May writes:
> I note that the previous version of tiff3 is a security update for
> tiff2pdf.
I also note that there seem to be a number of reverse depends of tiff3
in wheezy.
Here is a version of tiff3 available for testing.
https://people.debian.org/~bam/debian/pool/main/t/tiff3/
Unfor
Brian May writes:
> Now to see if the patch will apply to the older tiff3, also in wheezy.
Done.
I note that the previous version of tiff3 is a security update for
tiff2pdf.
However I also note that - for the tiff3 package - we don't build a
binary for tiff2pdf. The newer tiff package is used
> I have a version available for testing.
>
> https://people.debian.org/~bam/debian/pool/main/t/tiff/
Here is the diff:
diff -Nru tiff-4.0.2/debian/changelog tiff-4.0.2/debian/changelog
--- tiff-4.0.2/debian/changelog 2017-09-10 10:03:56.0 +1000
+++ tiff-4.0.2/debian/changelog 2017-12-11
I have a version available for testing.
https://people.debian.org/~bam/debian/pool/main/t/tiff/
Now to see if the patch will apply to the older tiff3, also in wheezy.
--
Brian May
On Fri, Nov 17, 2017 at 03:45:07PM +1100, Brian May wrote:
> Brian May writes:
>
> > --- tiff-4.0.8.orig/libtiff/tif_dir.c
> > +++ tiff-4.0.8/libtiff/tif_dir.c
> > @@ -1065,6 +1065,9 @@
> > if (td->td_samplesperpixel - td->td_extrasamples > 1) {
> >
Brian May writes:
> --- tiff-4.0.8.orig/libtiff/tif_dir.c
> +++ tiff-4.0.8/libtiff/tif_dir.c
> @@ -1065,6 +1065,9 @@
> if (td->td_samplesperpixel - td->td_extrasamples > 1) {
> *va_arg(ap, uint16**) =
> td->td_transferfunction[1];
>
Looks like this patch is required first, before fixing the problem I
referred to earlier, otherwise we use pointers in tiff2pdf that were
never initialized. At least for the version in wheezy.
Another solution would ensure the values are NULL before calling
TIFFGetField - this would mean we only u
Brian May writes:
> I added a comment to the upstream bug report:
>
> http://bugzilla.maptools.org/show_bug.cgi?id=2704#c14
Anybody got a sample (good) tiff file with transfer function tables?
I am a bit puzzled, as per last comment in upstream bug report, because
the tiff2pdf seems to be readi
I added a comment to the upstream bug report:
http://bugzilla.maptools.org/show_bug.cgi?id=2704#c14
--
Brian May
"Roberto C. Sánchez" writes:
> That sounds like a flawed assumption. The spec (I provide a working
> link below) describes the format of a TIFF as being made up of an 8 byte
> header and one or more images (IFDs, or image file directories).
>
> The descriptions do not explicitly say that each pa
"Roberto C. Sánchez" writes:
> That sounds like a flawed assumption. The spec (I provide a working
> link below) describes the format of a TIFF as being made up of an 8 byte
> header and one or more images (IFDs, or image file directories).
Yes, that was my guess too, although I couldn't find a
Hi Brian,
I tried looking at this when I prepared the last tiff and tiff3 updates
a couple of months ago. However, you went much deeper than I did.
On Tue, Nov 14, 2017 at 08:22:26AM +1100, Brian May wrote:
> Looks like this vulnerability - at least for the first test case - is
> because we assu
Looks like this vulnerability - at least for the first test case - is
because we assume that a tiff will only have one transfer function that
is the same for all pages. However, we read the transfer function for
every page.
Depending on the transfer function, we allocate either 2 or 4 bytes to
the
13 matches
Mail list logo
