Bug 22072 - Libtiff 4.0.9
Summary: Libtiff 4.0.9
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 6
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: QA Team
QA Contact:
URL:
Whiteboard: MGA5TOO MGA5-32-OK MGA6-64-OK MGA6-32-OK
Keywords: advisory, validated_update
Depends on:
Blocks:
 
Reported: 2017-11-23 10:03 CET by Nicolas Salguero
Modified: 2017-11-29 19:53 CET (History)
4 users (show)

See Also:
Source RPM: libtiff-4.0.8-3.mga6.src.rpm
CVE:
Status comment:


Attachments

Description Nicolas Salguero 2017-11-23 10:03:51 CET
Hi,

Version 4.0.9 of libtiff has been released.  It contains fixes for many bugs.  Some of them can be related to security problems as well.

Best regards,

Nico.
Comment 1 Nicolas Salguero 2017-11-23 10:10:45 CET
Suggested advisory:
========================

The updated packages fix many bugs.  Some of those bugs can be related to security problems as well.
========================

Updated package in 5/core/updates_testing:
========================
libtiff-progs-4.0.9-1.mga5
lib(64)tiff5-4.0.9-1.mga5
lib(64)tiff-devel-4.0.9-1.mga5
lib(64)tiff-static-devel-4.0.9-1.mga5

from SRPMS:
libtiff-4.0.9-1.mga5.src.rpm

Updated package in 6/core/updates_testing:
========================
libtiff-progs-4.0.9-1.mga6
lib(64)tiff5-4.0.9-1.mga6
lib(64)tiff-devel-4.0.9-1.mga6
lib(64)tiff-static-devel-4.0.9-1.mga6

from SRPMS:
libtiff-4.0.9-1.mga6.src.rpm

Assignee: bugsquad => qa-bugs
Status: NEW => ASSIGNED
Whiteboard: (none) => MGA5TOO
Source RPM: (none) => libtiff-4.0.8-3.mga6.src.rpm

Comment 2 Herman Viaene 2017-11-27 10:48:03 CET
MGA5-32 on Dell Latitude D600
No installation issues.
Similar tests as in bug 21195 Comment 7, all OK.

CC: (none) => herman.viaene
Whiteboard: MGA5TOO => MGA5TOO MGA5-32-OK

Comment 3 Len Lawrence 2017-11-27 17:30:37 CET
From the comment by Nicolas #1 we should expect a long list of CVEs I expect and maybe POCs as well.

CC: (none) => tarazed25

Comment 4 Len Lawrence 2017-11-27 17:32:46 CET
Mageia 6 on x86_64

Installed the four packages from updates testing.
Ran a series of tests based on bug 20057 comments.
These use some of the tools supplied by libtiff-progs:
tiff2bw    tiff2rgba   tiffcrop     tiffgt       tiffset 
tiff2pdf   tiffcmp     tiffdither   tiffinfo     tiffsplit 
tiff2ps    tiffcp      tiffdump     tiffmedian   tifftopnm 
There are others:
fax2tiff   raw2tiff    pamtotiff    ppm2tiff     pnmtotiffcmyk

$ urpmq --whatrequires lib64tiff5 | sort -u | wc -l
126
Dependent packages include imagemagick itself, xv, gqview, blender, scribus, tkimg....

Tried tiffgt to display several local TIFF images and it failed every time on images which display from GraphicsMagick could handle.
$ ppm2tiff abc1-1.ppm  ppmtest.tif
$ tiffgt ppmtest.tif 
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
X Error of failed request:  GLXBadContext
  Major opcode of failed request:  153 (GLX)
  Minor opcode of failed request:  6 (X_GLXIsDirect)
  Serial number of failed request:  44
  Current serial number in output stream:  43
X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  153 (GLX)
  Minor opcode of failed request:  24 (X_GLXCreateNewContext)
  Value in failed request:  0x0
  Serial number of failed request:  43
  Current serial number in output stream:  44

display showed the image without any problem and the fault does not appear in a 32-bit virtualbox for mga6 before any updating.  Checking this for libtiff 4.0.8 on a different machine the result is the same so it is not a regression but an unfixed bug possibly.

tiff2pdf and tiff2ps worked fine.  The outputs could be viewed with xpdf and gs respectively.
For raw2tiff raw data picked at random from amongst data files was presented using arbitrary width and height to produce an image of sorts.
$ raw2tiff -w 64 -l 64 /usr/lib64/evas/utils/evas_image_loader.raw test.tif
strace shows that raw2tiff uses the lib64tiff5 library.

$ tiff2rgba IMG_7898.tiff rgba.tif
This generated a virtually identical copy of the original colour image but the structures are different.
$ tiffinfo IMG_7898.tiff
TIFF Directory at offset 0xf180 (61824)
  Image Width: 320 Image Length: 240
  Resolution: 180, 180 pixels/inch
  Bits/Sample: 8
  Compression Scheme: JPEG
  Photometric Interpretation: RGB color
  FillOrder: msb-to-lsb
  YCbCr Subsampling: 2, 2
  Orientation: row 0 top, col 0 lhs
  Samples/Pixel: 3
  Rows/Strip: 16
  Planar Configuration: single image plane
  DocumentName: IMG_7898.tiff
  Software: ImageMagick 6.2.4 10/02/07 Q16 http://www.imagemagick.org
  JPEG Tables: (289 bytes)
$ tiffinfo rgba.tif
TIFF Directory at offset 0x4b94c (309580)
  Image Width: 320 Image Length: 240
  Resolution: 180, 180 pixels/inch
  Bits/Sample: 8
  Compression Scheme: PackBits
  Photometric Interpretation: RGB color
  Extra Samples: 1<assoc-alpha>
  FillOrder: msb-to-lsb
  Orientation: row 0 top, col 0 lhs
  Samples/Pixel: 4
  Rows/Strip: 6
  Planar Configuration: single image plane
  DocumentName: IMG_7898.tiff
  Software: LIBTIFF, Version 4.0.9
Copyright (c) 1988-1996 Sam Leffler
Copyright (c) 1991-1996 Silicon Graphics, Inc.

$ pnmtotiffcmyk piuva.pnm > Piuva.tif
The resulting image appeared with a different colour scheme where reds and yellows had been replaced by blues and greens.

$ tifftopnm IMG_7950.tiff > img7950.pnm
The pnm image looked exactly like the original colour tiff.

$ tiffcp PIA13706_fig1.tif santamariacrater.tif
TIFFReadDirectory: Warning, Unknown field with tag 37724 (0x935c) encountered.
_TIFFVGetField: santamariacrater.tif: Invalid tag "BadFaxLines" (not supported by codec).
_TIFFVGetField: santamariacrater.tif: Invalid tag "BadFaxLines" (not supported by codec).
$ identify santamariacrater.tif
santamariacrater.tif TIFF 8192x7051 8192x7051+0+0 8-bit sRGB 13.1717MiB 0.000u 0:00.000
$ identify PIA13706_fig1.tif
PIA13706_fig1.tif TIFF 8192x7051 8192x7051+0+0 8-bit sRGB 12.9884MiB 0.000u 0:00.000
$ ls -l santamariacrater.tif PIA13706_fig1.tif
-rw-r--r-- 1 lcl lcl 13619332 Jul 17  2016 PIA13706_fig1.tif
-rw-r--r-- 1 lcl lcl 13811488 Nov 27 16:21 santamariacrater.tif

They look the same anyway.

That is probably enough to clear this for 64-bits although we may choose to revisit it if POCs turn up.
Len Lawrence 2017-11-27 17:33:02 CET

Whiteboard: MGA5TOO MGA5-32-OK => MGA5TOO MGA5-32-OK MGA6-64-OK

Comment 5 Len Lawrence 2017-11-28 01:26:02 CET
Mageia 6 on i586 in virtualbox.

Checked tiffgt before updating.  It worked fine.
Copied a number of images from the host system and ran them against tiffgt, tiffinfo, ppm2tiff, tiffcp, tiff2rgba, pnmtotiffcmyk, tiff2pdf and tiff2ps.
All functioned as expected.  No regressions.
man pages are available for all the utilities tested.

Used tiffcrop to clip a 200 pixel wide border from a large TIFF image.
$ identify SantaMaria.tif 
SantaMaria.tif TIFF 1311x1128 1311x1128+0+0 8-bit sRGB 1.03356MiB 0.000u 0:00.000
$ tiffcrop -E top -U px -m 200,200,200,200 SantaMaria.tif crater.tif
_TIFFVGetField: crater.tif: Invalid tag "BadFaxLines" (not supported by codec).
_TIFFVGetField: crater.tif: Invalid tag "BadFaxLines" (not supported by codec).
$ identify crater.tif
crater.tif TIFF 911x728 911x728+0+0 8-bit sRGB 536899B 0.000u 0:00.000

Those "Invalid tag" lines appear elsewhere and have been seen in previous tests - they can probably be ignored.

tiff2bw works if the right colour image is chosen.
$ tiff2bw Piuva.tif grey.tif
Piuva.tif: Bad photometric; can only handle RGB and Palette images.
$ tiff2bw IMG_7898.tiff grey.tif
That works, producing a greyscale copy of the colour image.
$ identify IMG_7898.tiff 
IMG_7898.tiff TIFF 320x240 320x240+0+0 8-bit sRGB 62561B 0.000u 0:00.000
$ identify Piuva.tif
Piuva.tif TIFF 320x340 320x340+0+0 8-bit CMYK 298923B 0.000u 0:00.000

This looks fine for 32 bits.
Len Lawrence 2017-11-28 01:26:18 CET

Whiteboard: MGA5TOO MGA5-32-OK MGA6-64-OK => MGA5TOO MGA5-32-OK MGA6-64-OK MGA6-32-OK

Lewis Smith 2017-11-28 09:05:54 CET

CC: (none) => lewyssmith, sysadmin-bugs
Keywords: (none) => advisory, validated_update

Comment 6 Lewis Smith 2017-11-28 10:47:31 CET
Just to note that the advisory has *no* CVEs.
Comment 7 Mageia Robot 2017-11-29 19:53:37 CET
An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2017-0431.html

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED


Note You need to log in before you can comment on or make changes to this bug.